Hacker News new | ask | show | jobs
by the_overseer 1156 days ago
The industry works as follows: the OEM (Daimler, Toyota etc.) says they want a software spec implemented. Other companies (Tier 1 suppliers) bid to win the contract. The cheapest usually wins.

If you have a company and refuse to take the crazy deadlines and low quality and low pay then don't worry, there is another Tier 1 supplier across the street who will do it for you. OEMs know that you need them more than they need you.

5 comments

And on top off that, some product manager at Mercedes might say they absolutely need let's say Atmos in the next release and ask the Tier 1 to implement it. The Tier 1 usually uses multiple Tier 2s. The Tier 2s say they need more memory, but that's not practical at all because that hardware was fully validated years ago and you just don't make incremental changes to automotive hardware, and there won't be a hardware refresh for another 4 years. It is in none of the tiers' interests to say they can't do it and lose out on a multi-year contract so they do the best possible job within the constraints.
> Atmos

Well, that is evil by design irrespective of the particular implementation, no? ;-)

That’s fine. But the worst case response time across the entire UI must be the first item on that spec! That spec is of course the responsibility of the OEM to create. Where this goes wrong I don’t know but competition, price sensitivity etc doesn’t explain it. Having soft and hard limits for response time seems obvious and someone either forgot, or they had a meeting where they (the OEM, after deciding on a solution and having it implemented) said “ok we can save $20 on the BOM by going for a cheaper SoC if we accept 200ms response times instead of 50ms” and that should basically be criminal due to the safety aspect.
It's not criminal so they will continue to lower the cost. 50ms quickly becomes 500ms response time when you realize that no tier 1 supplier can hit within your OEM budget and your boss is becoming impatient :)

Another thing that happens is when there is a 50ms response time mandated and at the start of the project you have 30ms and it slowly creeps up until you get to 55ms. Then the blame game starts. Like I said previously, each component is usually won by a different tier 1 supplier. So everybody puts the blame on somebody else. One tier 1 is building the linux distro, the other is making basic system libraries and the applications are written by another 20 tier 1 suppliers.

Then the deadline hits and the car needs to be sent to the showrooms. So whatever 50ms was chosen initially is changed to whatever it currently is so to say they are within spec and can ship the damned car.

I think this describes a lot of how software is developed (which just goes to show how immature that part of the industry is.). Similar contracts and agreements exist between manufacturers of the brake system as well but if there is an issue there where the ABS system doesn't prevent lockup in 1% of cases, then the problem is solved or the car launch is delayed, because that's what the system is designed to do. The problem here of course is that these things are seen as gadgets without safety aspects and there is no regulatory oversight.

I guess it's also up to buyers: don't buy cars with shoddy infotainment.

ah, there is some regulatory oversight and there's awareness of the safety aspects.

Not much, but, there is some.

After working on infotainment, I'm doing my best to avoid purchasing a car with an infotainment system. I had to compromise and got a Civic with an infotainment system for my wife, but I'll probably stick to late 2000s, early 2010s for as long as I possibly can to avoid them. Seriously hate touchscreens, and there's just not enough value in an infotainment system for me to be OK with what I'm losing by having one.

Something missing here is that the Tier 1 supplier will take one look at the spec and know that latency hasn't been mentioned or considered.

They will not tell the customer this because either the customer doesn't care, so why waste time and resources

...or when the customer realises they will open a Change Request to fix the issue. Change Requests are how you make an actual profit on unprofitable, low-balled contract and probably gain an extension on the unachievable timeline agreed to win the bid in the first place.

The "customer" is the person that signs the contract not the user of the product. They probably don't care that it's a pig to use. It just has to look OK in a presentation to their boss (...who isn't going to ever use it either).

If Tier 1 suppliers didn't behave this way they wouldn't be able to pitch bid responses cheap enough to win bids. The responsibility for crappy products lies entirely with the product owners. Only they know what's good enough.

From what I observed product owners know that the system sucks and it's laggy. They also know that the OEM management only keeps repeating "cheap, cheap, cheap", "with a renewed focust on costs" and other sayings like these.
That was true and it might be true for most of the production process, but as you may read in this article https://arstechnica.com/cars/2023/02/mercedes-ceo-tells-ars-... they are actively working to change and speed up the software development process:

Källenius explained the current system to Ars Technica like this:

    "So some engineer in Sindelfingen comes up with a concept. You have to write that down. You have to send it to the supplier that needs to be quoted. Then procurement people need to negotiate with each other. Then that supplier goes to some sub-supplier in Eastern Europe and wherever they do. It goes back up the chain again. It gets tested and nine months later, you have actually changed something in your infotainment system. Now you go into the ESH [Mercedes' electric Software Hub]. To say, let's change this and you just do it."
Working on a product vs working on a project. The latter means that the usefulness of the thing produced is a non-goal because the customer is not a user.