That's a bit odd. Are they unaware of the last 30 years of computer history?
Even as someone with a background in mechanical engineering the degree of complexity behind some software products, such as Windows, is really impressive.
Even as someone with a background in mechanical engineering the degree of complexity behind some software products, such as Windows, is really impressive.
It used to be quite similar in South Korea until the more recent rise of domestic software giants like Naver and Kakao Corp.
In a lot of the East Asian countries, there is a large gap in desirability between the large, established employers and smaller companies due to outrageous differences in pay grade, benefits and job stability. So new business has a tougher time making it to escape velocity and offering significant numbers of jobs.
A recent experience at a neobanking startup from SE Asia reaffirms the point. Despite the product built around an API-only model, the firm was operations heavy when it came to decision making and investing in people, as it was believed to be the core company strength (for a variety of reasons including the institutional bureaucracy, corruption in these markets, etc.)
TL;DR people work where the money flows. Companies get what they pay for. And the investors pay for what they think is the strength or is likely to sell at inflated valuations.
About once a quarter I am subject to conversations where they remark condescendingly about how flabbergasted they are at SWE salaries. I stopped engaging beyond "Mmm if you're interested you should learn more about the field".
This interaction is beyond grating and is detrimental to our relationships.
The software development field is quite new compared to the other engineering disciplines and many, many decisions are made on gut feel, intuition or out right personal preference. Alan Kay has some very good talks on this specific subject, referring to the current state of our field as a Cargo Cult.
However, I would also say firmware would be the least expensive to engineer because the requirements for that type of software are better known and more rigid.
Even during development, the only cost of iterating over errors until you get it right is just time.
But HW engineers just don't have the luxury of making 100 iterations of a product until it works, nor the safety net of "we'll update it over the internet". They must put a lot of effort into testing and verification until they say "ok, this is good, let's ship it."
Also, failure modes of mechanical products are often known and intuitive.
I am guessing that before the advent of Internet, the average quality of shipped software was higher on average. Nobody would dare ship a hot mess like Battlefield 2042 if they knew it's the last version they ship.
Mech eng processes on one side, ASIL-style safety requirements in the middle, and someone wishing to pour a bucket load of Android apps into the same computer from the other end.
The discipline of robotics (which is really what you're talking about here — cars are just very manually-micromanaged robots these days) is all about subsumptive distributed architectures: e.g. the wheels in an electric car don't need a control signal to tell them to brake if they're skidding; they have a local connection to a skid sensor that allows them to brake by themselves, and they instead need a control signal to stop braking in such a situation.
This is why, in anything from planes to trains to cars, you see the words "auxiliary" or "accessory" used to describe infotainment displays et al — the larger systems are architected such that even an electrical fault (e.g. dead short) in the "accessory" (non-critical) systems can't impact QoS for the "main" (critical) systems.
I really can't imagine a world where they've got engineers building the car that understand that, but who are willing to let Android apps run on the same CPU that's operating the car. They'd very clearly insist for separate chips; ideally, separate logic boards, connected only by opto-isolated signals and clear fault-tolerant wire protocols.
In short: Yes.
The point you're making is valid in general and you provide valuable context. A modern car does have many different computers, and there is a lot of intentional partitioning (and even some redundancy) into different CPUs, as well as guests under hypervisors.
For example, a typical headunit computer (the "infotainment computer") tends to contain two to three SoCs performing different duties, and one or two of them will run hypervisors with multiple guest operating systems. And that is just one of multiple computers of that weight class in the overall car architecture.
That said, there's an overall drive to integrate/consolidate the electrical architecture into fewer, beefier systems, and you do now encounter systems where you have mixed criticality within a single computational partition, e.g. a single Linux kernel running workloads that contribute both to entertainment and safety use cases. One specific driver is that they sometimes share the same camera hardware (e.g. a mixed-mode IR/RGB camera doing both seat occupancy monitoring tasks and selfies).
Safety-vs-not-safety aside, you also simply have different styles of development methodology (i.e. how do you govern a system) run into each other within the same partition. AUTOSAR Adaptive runs AUTOSAR-style apps right next to your POSIX-free-for-all workloads on the same kernel, for example.
What however is typically not the case in that scenario is that the safety workload in a partition is the only contributor to its safety use case, i.e. typically you will always have another partition (or computer) also contribute to assure an overall safe result.
In more auto terms, you might now have ASIL B stuff running alongside those Android apps on the same kernel, but you will still have an ASIL D system somewhere.
In general, you will start to see more of both in cars: More aviation- and telco-style redunancy and fault tolerance, and more mixed criticality. The trends are heading in both directions simultaneously.
> I don't think that's true even in entirely software-mediated-control vehicles like Teslas.
Tesla has been in the media for bugs such as flipping tracks on your Bluetooth-tethered phone or opening the wrong website in the headunit web browser rebooting the Instrument Cluster display. This is an example of mixed-criticality (done wrong). Many other cars are not architected quite as poorly. However, IC and HU/central displays sharing the same computer (not necessarily the same computational partition/guest OS) is increasingly common.
In traditional engineering, there's at least a BOM and manufacturing processes that create pressure to keep things simpler. If physical items were engineered like software, you'd have people bolting a keyboard onto the monitor chassis they're designing because they needed an 'on' button, and keyboards have buttons. Obviously they'd then also have to add in an always-on raspberry pi to plug the USB keyboard into and emit a GPIO signal when the button is pressed. You'd get a lot more complexity, but for most of it, "impressive" would be the wrong word.
Bolting an entire keyboard on to a monitor to add a single extra button...
Thankfully the cost of adding physical atoms prevents such outrageously dumb ideas.
It's hard to overcome preconceived notions. As we know from politics, emotions are much stronger than logic. You can't simply say, "be logical!" or "change your view".