I’m pretty sure every airplane black box has every log entry of every computer in the plane. The thing is, you never have too much data when you analyze these things. Cause and effect chains can be long and surprising.
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Tesla infotainment system upgradeable from MCU1 to MCU2
- Thread starter MurrayJimW
- Start date
I’m pretty sure every airplane black box has every log entry of every computer in the plane. The thing is, you never have too much data when you analyze these things. Cause and effect chains can be long and surprising.
That's not really here or there, since this is not an airplane. The logging that is destroying the eMMC isn't worth destroying the eMMC over. And they have other places they could save the data that wouldn't be so catastrophic, if they really wanted to!
Not quite true. There are two "black boxes" on airplanes required to have flight data recorders per their type certificates:
- The flight data recorder (FDR) which measures key parameters and records them
- The Cockpit Voice Recorder which captures audio from the various radios, the pilot and co-pilot headsets and the ambient cockpit noise (a mic in the ceiling).
The FDR does NOT capture every entry or the logs from all the computers onboard. What it does capture is key flight perameters including speed, altitude, attitude, control stick and throttle positions, control surface positions, engine parameters, etc. There are many parameters captured (especially on the new, digital FDRs, but it is NOT analogous to a computer log. Rather think of it as snapshots of key system configurations, orders, positions and flight parameters.
All that said, it does appear that Tesla is logging a bunch of stuff which is appropriate in a prototype for testing/data collection which should not be logged in a production model...
And we have our own hacker, @verygreen, saying that he thinks that while the kernel logging contributes to the problem he isn't sure it is the majority of the problem.
/me waves.
no they don't. do sync logging, it's all async and they even increased commit time on ext3 to 120 seconds lately.
But I suspect it's really all those sqlite updates they do all the time that do them in (sure, it's a compounding problem and logs play a role too as do other writers)
I'm pretty sure regardless of commit time, fsync on a dirty sqlite database will also force everything else before it to be committed too assuming it's on the same filesystem. Or do they turn off ordered journaling too?
(Coming to think about it, the fix for obscene fsync IO delays on Linux only went into ext4 IIRC...)
Proflig8tor
Member
Sorta agree ... depends on the aircraft and airline. Delta even uses vibration sensors to predict failures before they actually occur. Different parts (bearings mostly) resonate at different frequencies. The data is sent to a Maintenance Control Center that will get the part and the jet to the same location so the maintenance can be done proactively which ensures operational reliability for the customers, increased safety and lower cost than having the thing go "KABLOOEY" in timbukto-nowhere.
Aircraft use ancient standards for data logging. But on top of those systems are datalinks that are beaming systems condition, switch positions and performance data to the operator's management in real time.
Whoever designed Tesla's autopilot hardware obviously had some knowledge of autoland hardware and certification in aircraft. The system redundancy in my M3 is basically CAT3b in aviation certification speak.
So the main difficulty is a connector mismatch? Something that Tesla would be able to very easily solve, correct? Seems like a a simple harness adapter would allow an easy upgrade from MCU1 to MCU2 from what you're saying here. A DIY upgrade without a pre-made harness would be more difficult though.
You do not quite understand me correctly. The connectors are fully consistent - but to install the first generation MCU from the second or MCU2 in the machine, you will have to reconnect some of the wires in the upper row of connectors. Some adapters and adapters are harder and longer to do than just rearrange the pins in the connectors.
To replace IC1 with IC2, you don’t need to touch anything at all, everything works and so
I may have mis-understood the original post. The term flight data recorder has a specific meaning and is in reference to the crash-survivable unit which captures key data for accident investigations. That is different that the various computers pulling data for maintenance purposes (especially in modern airliners where so many systems are computer controlled). As you mention, those units (where maintenance used to hook up a cable to download data) now often transmit data continuously to the airline's maintenance system so that maintenance can do trend analysis, predictive maintenance and be prepared with the necessary tools and parts when the plane lands. My recollection is that most of this data is stored in some sort of nonvolatile memory in the avionics bay but is not protected from crash/impact/etc. in any way like the FDR.
The problem with that is that unless everyone pays the core charge and keeps their failed MCU there will always be more for them to refurbish. And they can always raise the core charge to discourage people from keeping them.
they use ordered journalling.
I did not investigate if they do sync db updates or not yet.
How come you think you know better than tesla what the relevance of the data is? They clearly want to keep that kernel alive and well, so there is probably quite a lot of relevant stuff running in it. Even with the latest software version all kernel logging is on while the car is moving. Now it shuts down while being parked, though.
Do they journal data as well? Default mount options journal metadata only. Data lands in the writeback and can be lost on crash. Default flush timer is set to 5 seconds I believe.
they are not journalling data, but ordered journal means that before transaction flushes all data referenced by transactions about to commit would be flushed. Also like I said they now set flush/commit interval to 120 seconds.
Do they also tweak the dirty_background_ratio and the (whatever it’s called _centisecs) which control how often pdflush writes out the write back cache? The journal commit interval alone won’t stop non-metadata dirty blocks from being pushed out to disk at a much more regular interval.
hm...
Code:
# cat /etc/sysctl.d/20-dirty-bytes.conf
# Start commiting dirty pages to disk as soon as they hit the cache.
vm.dirty_background_bytes = 5000