4 ms·

Wouldn't be shocked if infotainment does too. What else should they use?

nanolith 3y ago
None 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 ago
  I 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.

None 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 ago
I 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.