>some models simply won't run if the infotainment system is broken; the navigation GPS provides the vehicle's master time counter, and without that, the powertrain won't function
:O
:O
This is not surprising, as the team structures, at least as of a few years ago, were traditionally set up with tradtional manufactirng in mind, around parts and control modules, while the functionality exploded (within 1 or 2 generation of cars) and crossed those boundaries without adequate processes in place properly architect the interactions from a bird's-eye view, creating major computing power, network bandwidth, and most importantly to OEMs, cost bottlenecks.
And as cost is king, nobody wants to budge on increasing cost on their own module, and critical architectural decisions aren't made as much as put off until there isn't any other choice left except to hacking in the most critical bits with one eye closed and hoping somebody else's jenga tower falls first.
That, I imagine, is how you get that GPS time thing, I can see how it all started: "Oh, I can save $.30 on my module if I don't put in an RTC, that'll get me a nice bonus for cost saving, GPS is going to have one anyway ..."
One time I was working on a new project and I wanted to put an SD card on the board so that we could have a log. I was asked how much the log was "worth" so that they could justify the cost of the extra hardware.
Very much like testing. Incalculable if you need it (and you certainly do), but managers who don't understand, just assume that you're doing something wrong if you need to "waste time" reading logs or writing tests rather than adding features.
You answer that question with a question, how much is a one month delay in shipping worth to you?
In the business world there is a lot of room for BS so people get away with it. But in software, it can doom a project.
You feel that in today's infotainment and electronics integration in vehicles.
For example, ovens with clocks keep track of time through the grid frequency and if the grid frequency changes, the clocks diverge too.
Compare to a typical quartz oscillator which will gain or lose around 15 seconds per month.
Also, I guess that means my devices with clocks that drift more than two seconds, ie several full minutes, are actually using crystal oscillators? I guess it makes sense for a microwave which needs second level granularity, but that seems odd to me.
The crystal in your microwave's CPU clock circuit will drift, and so will the time-of-day derived from it until you set the time again, if there is no external reference. The benefit of using the incoming 50/60Hz AC signal as a timebase is that the power station is responsible for controlling the long term frequency to avoid drift so it can be used as a very reliable reference.
And that engineer who writes code might be a brilliant engineer and competent coder, but they just haven't been on many software projects before and they don't see how damning that decision could end up being.
It works and everyone is happy, but it's a wart that people have to build around for the next 20 years.
I deal with this stuff semi-regularly in my day job and wow.
It's a complete nightmare to integrate with the rest of the application.
Also, crystal oscillators aren't that accurate. You can make them more accurate by heating them to a given temperature, but this is something only done in expensive test & measurement equipment.
I don't disagree with you that grid frequencies are generally very accurate and they are a practical clock source for cheap clocks, I just found that interesting.
[1] https://www.reuters.com/article/serbia-kosovo-energy/serbia-...
But since the infotainment already dealt with time, they just used that as a "system clock" straight, so without infotainment there's no "system clock" to be had.