If this happens, I might finally get the open-source backing and funding I need for my dream of having a "car neutering" service available.
Pick a popular recent model vehicle with decent mechanical/structural design and offer a complete revamp with new ECUs and consoles that are drop-in replacements for the OEM ones.
In rough order of priority (factoring both importance to safety/usability and complexity of implementation):
1) Remove every radio transmitter, cell modem, telematics phone-home feature, etc
2) Replace all touch screens with physical knobs and buttons
3) Remove every "self driving" / "driver assistance" feature or, at absolute minimum, add a big red e-stop button that physically powers down all ECUs and sensors providing such antifeatures and reverts to full manual control
4) Replace all ECUs responsible for safety-critical functionality like throttle control and ABS with new ones built with memory-safe firmware, triple modular redundant processors with ECC RAM, and (ideally, although this would be more invasive in terms of required modifications to the vehicle) redundant sensors and actuators so that failure of say a single pedal position sensor won't lead to a loss of control.
I think the implementation I'd trust most for life-safety software, with current technology, is probably an FPGA based platform compiled with open tools and end to end LVS from bitstream to RTL, running three copies of a riscv-formal validated CPU core with a majority voter on the outputs and SEU scrubbing on the configuration memory. The technology to build this either exists today or is close to available, although at the cost of performance vs more mainstream solutions.
Formal verification of the software control loops would be great too. Anybody know what the state of the art in formal correctness tools for Rust code (in terms of algorithmic bugs rather than the safety properties checked by the compiler and runtime) is like?
Andrew Zonenberg
npub1wp…rf386
2025-02-26 14:54:21 UTC
in reply to nevent1q…dhm3
Author Public Key
npub1wpgh8qdt8suzxy8f2luspksj4wpdfw53weq4v8dr7llqp3t72tds3rf386Seen on
wss://relay.momostr.pinkPublished at
2025-02-26 14:54:21 UTCEvent JSON
{
"id": "f4e9fa09b2b89d36c31eaebaa72bfac50bd99cff21d7010e4c313ece38ec4fd8",
"pubkey": "70517381ab3c382310e957f900da12ab82d4ba917641561da3f7fe00c57e52db",
"created_at": 1740581661,
"kind": 1,
"tags": [
[
"p",
"a3af17104f91f7f9b5667b14717d1d434931195e4c6e075b7dc13d8ed71bc46f"
],
[
"e",
"a71811d6a804573c389a647a1b305c309f15fb63522b55ab4a44a48e01161745",
"",
"root",
"a3af17104f91f7f9b5667b14717d1d434931195e4c6e075b7dc13d8ed71bc46f"
],
[
"proxy",
"https://ioc.exchange/@azonenberg/114070759739409466",
"web"
],
[
"proxy",
"https://ioc.exchange/users/azonenberg/statuses/114070759739409466",
"activitypub"
],
[
"L",
"pink.momostr"
],
[
"l",
"pink.momostr.activitypub:https://ioc.exchange/users/azonenberg/statuses/114070759739409466",
"pink.momostr"
],
[
"-"
]
],
"content": "If this happens, I might finally get the open-source backing and funding I need for my dream of having a \"car neutering\" service available.\n\nPick a popular recent model vehicle with decent mechanical/structural design and offer a complete revamp with new ECUs and consoles that are drop-in replacements for the OEM ones.\n\nIn rough order of priority (factoring both importance to safety/usability and complexity of implementation):\n\n1) Remove every radio transmitter, cell modem, telematics phone-home feature, etc\n\n2) Replace all touch screens with physical knobs and buttons\n\n3) Remove every \"self driving\" / \"driver assistance\" feature or, at absolute minimum, add a big red e-stop button that physically powers down all ECUs and sensors providing such antifeatures and reverts to full manual control\n\n4) Replace all ECUs responsible for safety-critical functionality like throttle control and ABS with new ones built with memory-safe firmware, triple modular redundant processors with ECC RAM, and (ideally, although this would be more invasive in terms of required modifications to the vehicle) redundant sensors and actuators so that failure of say a single pedal position sensor won't lead to a loss of control.\n\nI think the implementation I'd trust most for life-safety software, with current technology, is probably an FPGA based platform compiled with open tools and end to end LVS from bitstream to RTL, running three copies of a riscv-formal validated CPU core with a majority voter on the outputs and SEU scrubbing on the configuration memory. The technology to build this either exists today or is close to available, although at the cost of performance vs more mainstream solutions.\n\nFormal verification of the software control loops would be great too. Anybody know what the state of the art in formal correctness tools for Rust code (in terms of algorithmic bugs rather than the safety properties checked by the compiler and runtime) is like?",
"sig": "4f616e1319091dd54d33207e8eeecbefeeaf22c74436c3b0cddc52a45e35fcfd89e8438fe03be1e0dee797b13bf226704c49d75e897373f7bc77619f33120331"
}