Join the WhatsApp group here.

The problem

Nowadays, repairing hardware electronics is impossible or almost impossible. Current practice forces a car owner to replace instead of repair. This has a really high cost and pushes owners to seek other less trustworthy solutions using used components from other vehicles. Since this type of components is nowadays heavily protected, maintenance and repair outside the official car manufacturer authorized dealer poses additional risks every time a piece of hardware electronics or firmware requires reverse engineering and modification just to enable it and make it work in another vehicle.

The Ideia

Design and prototype OEM hardware electronics capable to the same operation and functionality, however instead of using closed and protected logic, it uses open hardware and open firmware hardware electronics as a direct replacement into existing* wiring in a vehicle, in particular older cars. This will facilitate repeatability and maintenance on any "repair shop" outside authorized dealers. And requires no reverse engineering and no modification to make it work in a vehicle.

Since this is an open hardware project, the main selection of choice for the operating system will be Android Auto for the main LCD screen, in the center console. Nowadays there are a plenitude of "open auto" solutions using a raspberry pi. I'll be designing the hardware electronics made to fit an SoC module, and I'll be starting with NVidia's Jetson Nano. In the following YouTube video there's a good example of a traditional media unit https://www.youtube.com/watch?v=RgbHXTHUnQw

Open Hardware Design Considerations

Since these "open automotive" solutions are based on "open hardware" electronics there are some design considerations to make the electronics safer when driving and also make it simple & easy to troubleshoot, debug and repair. When deploying open solutions, one of the major requirements to have, is redundancy. This means in case of failure of a particular electronic component there's a 2nd one (or more) ready to take over the one malfunctioning. Depending on safety requirements, this type of redundancy can be implemented in the same hardware electronics installed in a particular location in a vehicle (see hardware electronics of a Tesla car), or can be in a separate hardware electronics installed on a different location in a vehicle. Another hardware design consideration is on having a separate microcontroller dedicated exclusively to CAN communication among devices installed in a vehicle and able to communicate directly to the control module's main microcontroller. By having a separate microcontroller one is minimizing the possibility of malfunction of the controller in the event of unauthorized intrusion "hacking" of the CAN bus network. To add to safety and security of all open hardware electronics proposed and available on this repository, it will use many of the functionalities, specifications and characteristics described on this ongoing scientific research paper titled "Validation of Experimental Data Origins: A Swarm of DAQ devices able to Deliver Unique Experimental Data using Blockchain‐like Fingerprint ID to a Data Repository".

The Open ECU

To design the open hardware electronics ECU I'll be using what is already available on the open communities in particular the Speeduino project (see its GitHub repository here). Their open hardware ECU solution is a flexible, fully featured Engine Management Systems (EMS aka ECU) based on the low cost and open source Arduino platform. It provides the hardware, firmware and software components that make up an engine management system, all provided under open licenses. With over 1000 installations, Speeduino has matured into a product that meets the needs of the hobbyist and enthusiast community without driving prices to the levels of traditional aftermarket ECUs.

image.png


To run the main electronics and engine management I'll be using EspressIF Systems ESP32 C3 microcontroller a single core Xtensa LX7 Core Processor running at 160MHz with 400Kb RAM and of 4MB PSRAM. This microcontroller serves the purpose of CAN communications with other hardware electronics in a vehicle and relays validated data to the main microcontroller. It has wireless radio capabilities that are disabled on the hardware electronics itself for safety concerns. Instead, the hardware include an optional chip for wireless connectivity that needs to be enabled first, for instance, by a mechanic, to enable wireless communications directly with the ECU. The main MCU, the MK64FX512VMD12 from NXP, is a Kinetis® K64 MCU, Based on Arm® Cortex®-M4 Core, running at 120 MHz and it has 256KB of SRAM (also found on the Teensy 3.5). This is the main MCU that is responsible to do real-time engine management of a vehicle. The first hardware revision will be made to fit engines with up to 8 cylinders with an option to run bi-fuel systems such as LPG, each with its own engine map configuration. In regards to safety against theft the electronics will include a cryptographic IC that will be used to match the car owner VIN number and with all other open hardware electronic components installed on a vehicle. In practical terms this means, in the event of theft, to make a specific open hardware work on another vehicle, it will require replacement of the main microcontroller processing unit without the need of specialized tools and equipment.

Selection of Connectors and Enclosure

I've selected an OEM aluminum enclosure for the open ECU being designed and prototyped. This OEM ECU housing is sold on AliExpress here and it has a plug connector with 90 pins that should be more than enough for this project. There's also an ECU housing in aluminum with 121 pin, one that uses a PCB Mount Header reference 1241434-1.

image.png

Open Hardware Electronics

The KiCad Project files for the very first revision of this open hardware electronics is now available! Find it on the folder "KiCad OPEN ECU". This is a non-working and not tested hardware electronics and is intended only for those curious to see the design working happening. If you're not into KiCad, the circuit schematics in a PDF format can be found on the folder "OPEN ECU Circuit Schematic". The KiCad footprints for this open hardware electronics can be found here. To view the full hardware specifications of this open hardware go here.

image.png

This OPEN ECU is being partially sponsored by

image.png

one final note about the author

The PCB Design Files I provide on GitHub for anyone to use are free. If you like this Smart Device or use it, please consider buying me a cup of coffee, a slice of pizza or a book to help me study, eat and think to work on new PCB design files.

Make a donation on PayPal and get a TAX refund*.