Open Hardware Design Considerations - aeonSolutions/AeonLabs-AI-Volvo-MKII-Open-Hardware GitHub Wiki
Main Page >> Open Hardware Design Considerations
Last change 11-02-2024
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".