4 ms·
Ah yes, the motor industry, which with the exception of Tesla delivers some of the world's most miserable, buggy, unpleasant-to-use infotainment software, cripp
by Longhanks 3y ago
Ah yes, the motor industry, which with the exception of Tesla delivers some of the world's most miserable, buggy, unpleasant-to-use infotainment software, crippled by bureaucracy, introduces more of the latter in order to micromanage software developers even more.
Thanks, but no, thanks. I'd rather you completely stop developing software and just let me plug in my phone. The less software my car runs, the safer I feel, and I need nothing more but navigation and music, which my phone handles just fine.
- coumbaya 3y agoIn general you would apply MISRA only on some critical parts of the software, and the infotainment wouldn't be part of this. At least it was like this when I applied MISRA on high speed trains, and when I worked briefly at the company that invented the airbag, their infotainment box was a windows embedded with 0 SIL2+ software on it. (But I agree with your point tho).
- nanolith 3y agoMISRA isn't typically used in infotainment systems. It's used in safety critical systems, like the car computer, which manages the monitoring and adjustment of fuel to oxygen mixture in the engine.
- P_I_Staker 3y agoWouldn't be shocked if infotainment does too. What else should they use?
- nanolith 3y agoNone of the fancy infotainment systems I observed the last time I went car shopping were likely to use it. They were based on third party frameworks and tools -- e.g. Android -- that weren't or couldn't possibly be built following this standard. In general, systems that are safety critical or adjacent to such systems should use formal methods. On many newer vehicles, like the Tesla Cybertruck, the infotainment system also doubles as the instrument display, which makes it safety adjacent. As such, it should also use formal methods. Model checking, based on satisfiability, is a relatively low bar to achieve. MISRA is a decent idiomatic framework that brings one closer to safe coding practices. However, it's not foolproof. Formal methods in theory _is_, but in practice it is not. Defense in depth is useful for designing and writing software. A good idiomatic style, unit testing, and formal methods each provide complementary checks. So, my recommendation would be to choose a good idiomatic style -- and despite its relative complexity, MISRA is a good idiomatic style from a safety perspective. Then, build a good automated testing culture. Incorporate model checking, especially through any execution path that is safety critical. Finally, architect the system so that failures in things that don't matter (video, audio, "games", or navigation) don't impact things that do matter (instrument display or communication with critical systems).
- P_I_Staker 3y agoI mostly agree, but don't be so sure that there's no C code, because if there is, you'd think they'd at least run it through the analyzer and say they looked at it and addressed the scary ones. I think infotainment actually does sit within the safe software process. Likely the lowest. I think static analysis recommendations could be relaxed for ASIL-A... I believe strongly recommended otherwise, which basically means, "you most certainly must do". Worth pointing out that MISRA is NOT required, even for higher levels; compliance to a standard is. I'm just guessing though chance of C code not so small, if so likely claiming some amount of MISRAness. Though you don't have to do MISRA it's the de facto choice. They might say we're ASIL-A it doesn't matter. Actually, I think development under those frameworks has ASPICE implications, and many of the same considerations.
- rightbyte 3y agoMisra rules are not what is wrong with automotive software development. I would say it is like 99% a wage problem.
- SV_BubbleTime 3y agoI’m much closer to this. A few issues… - Most people have no idea how many modules there are in their vehicles. It’s a LOT more code than you realize. - Companies like ERAS, Vector, Kvaser, Mentor, Bosch, and others have a great lock on software for systems they steer via SAE and ISO. - AutoSar and other shitty systems. It doesn’t matter how good your programmers are if they are kneecapped out the gate. - Same as any programming lately at big companies… it’s 10 managers to every actual programmer. - Outsourced. When I was at a Chrysler, code was worked on, released, and tested locally for some modules. Now… often times no one at Chrysler may even be allowed to see code. A LOT of work is done in India. MISRA isn’t even close to a problem in automotive. And I disagree it’s a wage problem. You could pay the engineers in India more, and it still wouldn’t give them any idea how the consumer will use the end product. It doesn’t help them understand repair/replace diagnostics. No one is monitoring the ever increasing complexity of the systems as a whole. Overall, cars do work well. But damn if they aren’t trying to ruin that.
- rightbyte 3y agoYe maybe. Agile is a nightmare in automotive since the process is so strict and the ensuing micromanagement makes doing thing a gigantic burden. Companies like Bosh have a strange dev process where they don't want to change code but instead make almost everything tunable by parameters so that you essentially can program via config, to get around some internal process. Their code is a nightmare to interface with. AutoSar is a joke. I would rather each device have their own API then dealing with that dynamic complex mess.
- P_I_Staker 3y agoI'm very disturbed by some things, specific to the most recent vehicles especially. Lots of design done by competing teams that have tons of incentive to say things like "not my problem!", and point fingers. Somewhat related to the proliferation of AutoSAR, but AutoSAR is just the solution, whether you like it or not. It could be replaced with some hypothetical "PerfectSAR", and this remains true. None of this is exactly brand new. That said, the extent of the situation is worrying. Combine with this that we're trying to deliver so much more on tighter schedules... seems like a recipe for disaster.
- aaronmdjones 3y agoYour car is running a hell of a lot more software than what you've just described. The ECU manages the engine; the BCM manages lights, wipers, airbags, and seatbelt pre-tensioners; you'll also have ABS (anti-lock brakes, so you can steer while braking instead of plowing straight ahead regardless of the orientation of your wheels) and either Traction Control or Electronic Stability Control. Every single one of these things is safety-critical, whose failure could cause a crash before you can react to it. It's this software that's written to the MISRA standards.
- krater23 3y agoYou would wonder how much software of parts in your Tesla is written by this big bad german car suppliers that all work under the MISRA rules. Would the critical software things of a Tesla be written by Tesla with their quality understanding, then this cars would be just death traps.
- nolist_policy 3y agoInteresting, have a link?
- P_I_Staker 3y agoHmm, what do you mean? I think this is mostly public knowledge. I don't know how much Tesla tries to inhouse, but I would guess it's roughly similar to other OEMs (kinda a wild guess tho) Most of the components are designed by suppliers they partner with. I don't know that you're going to find a good hyperlink for this stuff.
- P_I_Staker 3y agoThis ship has sailed, bro. lol, the year 2000 called they want your car back