ProfCJJ wrote: ↑Thu Nov 17, 2022 10:03 am
Other questions worth asking: is it running Automotive Grade Linux, and what hardware/cpu is it running on?
I’ve been reading up on Linux in automotive applications and there are standards to do with “fail safe” etc - I wonder how much these standards have been adhered to??
AGL seems to be a specific open source project rather than a standard. You can read quite a lot from the sponsorship levels. There are three platinum level car manufacturers (who are probably driving the design goals and perhaps using AGL extensively) and a lot of component manufacturers at the bronze level (who are probably mostly following, and perhaps influencing the design), with a few at the intermediate levels.
The safety standards almost certainly apply to braking, engine management etc. systems rather than information systems (like the instrument cluster), except where they relate to the bus interactions [which should be isolated from the display logic, and probably always monitored rather than updated]. An instrument cluster is essentially a read-only application, and should be self-contained without any strong real-time
requirements (accurately displaying road speed is probably the most stringent requirement, but the regulations have to cover old-fashioned
needle dials - my mother's A30 used to bounce between about 25 and 35 when she was doing 30mph, depending on the state of the
cable and how worn the gearbox connector was
I'm fairly sure even amateur Linux code would be better than that!).
There are hardware standards that should be followed (eg ASIL B) and you don't want the cluster to fail/reboot, but in normal use, the worst that
should normally happen is that you temporarily lose information about speed etc and need to pull over to restart the system.
Without knowing this particular panel, as a general rule, I'd expect conventional instrument panels to be less reliable than digital ones
at a hardware level (many cheap components that can fail independently and have unique applications, versus fairly standard processor and
display technology that is simply adapted to the automotive setting). The useful lifetime is a bit hard to predict. I'd expect the hardware to
be solid state, so the main risk would be the quality of the soldering, or maybe component failure.
The very worst scenario would involve replacing the failed cluster with the original one, or a new replacement.
For safety-related automotive software applications, there are other development standards that people follow, eg MISRA and AUTOSAR.
I've worked with people who have supported these. It's quite an interesting space. As you'd expect, avionics has even more stringent requirements (adding a comment to a single line of code requires the whole Airbus codebase to be recompiled and tested, and they have very strong real-time and software/hardware separation/replication requirements - they even use 3-core systems for redundancy).
It'll just be my thoughts on the cluster and how I'm getting on with it. I was originally going to include this in the first video, but decided to leave this just as a How-To and separate my thoughts. Hopfully I'll get this done this week 
This appears in the centre of the screen between the speedo and rev counter, or to the left in Sport+ Theme.