Car companies, both electric and non-electric, frequently advertise rated horsepower of their vehicles, even non-performance vehicles. In the US, horsepower is one of the key metrics for a vehicle overall.
As somebody currently working at an automaker on software systems, the amazing thing to me is that a mess up of this level doesn’t happen weekly. It’s rough out here.
Thank you. At least you're honest about it, the other day someone was trying real hard to convince me that software developers at automakers are made of magic fairy dust.
Relatively crappy pay, complex toolchains, long build times, layer upon layer of (really bad) legacy code, badly specified (if they're specified) protocols between subsystems, subsystems that are completely opaque (no source code provided), homegrown OS's or older RTOS's, subset-of-C to keep it safe(r), tricky debugging environments and if you're really unlucky anemic hardware.
I hope I didn't miss anything but I wouldn't be surprised if I did.
Yeah, I think you missed something. The "software architects, heavy enterprisey tooling, and minions" approach to development where some of the architects could be good developers, but they don't develop, and the minions are often not that good and also not given any autonomy, so they are in a state of learned helplessness and just do what they're told without much thinking or initiative. It results in over-abstracted, over-complicated, slow, unreliable, and sometimes just stupid code.
Automotive varies widely between "basically modern Linux systems with proper updates" and the most janky, home-grown update systems imaginable, sometimes even within the same components and teams.
Yah, I know from friends at ford and vw that there's still vxworks and qnx, but even there, good grief, a-b with confirmed boot is about as basic as you can get.
I confess I've seen incredible sloppiness about when a confirmation is done (too early, including in the initial init stages which is way too soon) and watchdogs (spawn off a process that has a while loop stroking the wd - just absolutely pointless).
I've heard all of the above, often "stroking". I never used those because I like systems where you have a random challenge code to respond to. Then the software has to not be acting as wonky to react correctly.
Indeed, a good RTOS from 10-20 years ago works just as good now as it did back then. The only things that change are dev environments and the driver support.
Do you have a source for this? There’s a gap between semi wheels, sure, but the deck height of a semi trailer in North America is about 48”. If automotive radars weren’t able to detect objects above this height, they would miss a lot of obstacles…
One automotive radar I’m familiar with, the Bosch MRR [1], lists a vertical FOV of ±15 degrees, and a 300 m maximum detection range. Assuming the sensor is mounted perpendicular to the ground at 0.5 m high, it should be able to see the top of a 13’6” semi trailer from ~15m away all the way up to its full range.
Teslas don’t have radar anyway, so of course this wouldn’t have helped, but an AEB radar that can’t see the top of a semi truck isn’t very useful.
Radars are usually tuned to ignore them because they don't have the fidelity to differentiate between a trailer on it's side and a tunnel and it leads to phantom braking.
If you are implying that in the recent era - we'll look at 2013 leading up to same-sex marriage being legalized - that there was rampant homophobia, the data does not support your claim.
According to the FBI, in 2013 there was 334 hate crimes committed against LGBTQIA+ people [1]. The US population back then was 315 million [2]. In 2013, according to Gallup, 3.6% of Americans identified as LGBTQIA+ in 2013 [3]. Which means the crime rate was 1 per 33,952 persons, or normalizing to per 100,000 as crime is usually reported is 2.94 per 100,000 which is on par or LOWER than any other category of heinous crime for that era. In fact, 2013 has one of the safest years on record [4].
Furthermore, public sentiment had already switched in favor of same-sex marriage before it was even legalized, according to Pew research [5].
I work in the space and I have not been impressed by the quality of Thatcham’s requirements once you get past the physical domain (door handle pull force, steering column locks, etc).
Yep - and not just between automakers, the security model varies wildly between different electrical architectures from the same manufacturer. Like any industry, there are hard problems, some of which are technically difficult, and some of which are self-inflicted from history/culture/insularity. No sector with any significant value or market competition has only the latter.
I work at Ford on vehicle access and security and I’m quite familiar with CAN security challenges and solutions. (Of course, I don’t speak for my employer here.)
Without speaking specifically to Ford’s plans, authenticated CAN communications are absolutely coming. I don’t see many approaches that actually encrypt the data on the bus - instead a MAC is used for each frame with a shared key on both secure ECUs, and some protections against replay attacks and such.
I wouldn’t expect all CAN data to be protected by this kind of security - it’s a pain in the butt, and expensive. Instead, certain specific sensitive information (like whether there’s a key in the ignition!) is protected as needed.
The industry is also moving toward IP-based communications for a lot of vehicle networking, which comes with many of the benefits of the modern infosec world. Automotive has a lot of unique challenges, though - like another poster mentioned, key provisioning and management is a huge pain; latency and hard timing constraints are way more important in the onboard/embedded world; many automotive ICs have limited support for e.g., asymmetric encryption, and of course there’s a lot of pain generated from the way the industry does software development generally. It’s an interesting space.
This comment touched on a lot of the wrestling that I’ve been doing for the past couple of years with my relationships to productivity, intentionality, and fulfillment. It’s a really useful perspective and validated some of my feelings. Thanks for writing it.
* limit max current (dumbest)
* limit max current based on moving average of current over last N seconds
* limit max current based on experimentally validated thermal model of contactors (cleverest)
This might even be possible without a significant/noticeable performance hit, if the overheating is only experienced in extreme conditions.
