Open Hardware Design Considerations - aeonSolutions/AeonLabs-AI-Volvo-MKII-Open-Hardware GitHub Wiki

Main Page >> Open Hardware Design Considerations

Change language
Last change 11-02-2024

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".

๐ŸŸข Automotive Components Stores

๐ŸŸข Useful utilities

โš ๏ธ **GitHub.com Fallback** โš ๏ธ