5 ms·

Best as I can tell from reporting, this is not about self driving at all. VW (which owns Cariad?) is unhappy with the pace and quality of the structural softwa

Best as I can tell from reporting, this is not about self driving at all. VW (which owns Cariad?) is unhappy with the pace and quality of the structural software being produced. Structural software impacts both operation of the vehicle as well as “infotainment”. There seems to be a lot of chatter that the German automobile manufacturers are hardware focused to a fault and don’t understand the needs/limitations of software development. Maybe that’s just gossip though.

Y_Y 3y ago
The article states that the purpose of this new "structural software" was to enable level 4 autonomy in the future.
- detaro 3y ago
  That's mostly because you can't run a big automotive software project and not say that, not because it's in any way doing direct work towards that goal.
detaro 3y ago
Not just German ones... Generally, for a long time they treated components with software the same as any other component: You buy it as a standalone thing from your suppliers, who make it according to your specifications, e.g. lots of the electronics would come from a "tier-1" like Bosch, who many cases farm out making of different parts to their suppliers, who then contract bits from subsubcontractors, ... and in the end everything gets plugged together. The car maker at the top of the pyramid is giving some goals/designs and tests if everything fits together and shouts down the chain if it doesn't. And for physical parts and contained software that does kind of work. It involves a lot of specification writing and -checking, but that's what mech eng orgs are good at. A simple digital instrument cluster isn't that different from an analogue one in that regard, in the end it is "hardware has to have this shape, fulfill this spec, display has to read the following CAN signals to show what's needed". Similarly for a navigation system or software on a engine control unit. Where exactly the lines between what was done in-house and what is contracted fell varied (e.g. some at least nominally controlled the software platform for e.g. the navigation/entertainment unit themselves, others bought that too from the Tier-1 and ordered design customization as needed), but in general the car company is mostly doing "managing" and coordination. But this has a bunch of downsides: If you don't have the expertise in-house, you are beholden to what your suppliers can or are willing to do. If they do bad work, you can shout at them (and car manufacturers are quite good at shouting at suppliers), but you can't fix or potentially not even properly evaluate it. Integration across subcontractor trees is difficult to make work well and leads to even more spec-writing and shifting blame if it doesn't go well. Since the tier-1 is probably also not a software company, the software expertise is somewhere deep down the contractor tree and not properly involved with the high-level decisions. E.g. a common complaint is why the UI in cars is so sluggish: What do you expect if the people deciding about the hardware didn't have trustworthy input from people actually building the software and the software is a hodge-podge from multiple suppliers forced to work against interfaces one supplier made up without concern if its useful for the others... or even pass rudimentary common-sense tests. It also gets way worse the more integrated things become. E.g. if you have a separate box for the navigation system (in some cars it's literally a box somewhere you can take out and replace if you get a map upgrade, which gets power and a screen connector from the car), there's little to no software integration needed. In a modern fancy-ish car, the expectation is obviously that this is all integrated in one UI, the navigation can appear in the instrument cluster, map updates should probably be online and not require bringing the car to a dealer, you want one central computer instead of multiple small ones, ... So to stop all this falling apart, someone needs to own it. The Tier-1 could, but it also doesn't have a clue how and the manufacturers obviously don't want to give those more power, so they try to bring it in-house. But if you've never had a internal culture for software to grow this from, it is really hard to do that. VW specifically said they'd do it by force, with plans to hire thousands of software people over a few years to build a totally new software division that would own the entire stack from scratch. It's going about as well as one would think something like that would go... Other manufacturers who noticed this earlier and let it grow slowly are faring better. Some had more experimental "labs" divisions which were closer to the software world, whose expertise now can be used. Some have accepted they have to farm some of it out and e.g. adopt Android Automotive, even though the industry was very hesitant about that initially (because it gives Google all that juicy user data and ownership over the connectivity services the industry really would rather control itself).
konschubert 3y ago
> Structural software impacts both operation of the vehicle as well as “infotainment”. From my limited insight, it seems that they are tightly coupling these two together: operational embedded code and the infotainment layer. So they cannot roll out a UX update without also updating the embedded code that steers the vents.

Y_Y 3y ago

The article states that the purpose of this new "structural software" was to enable level 4 autonomy in the future.

detaro 3y ago
That's mostly because you can't run a big automotive software project and not say that, not because it's in any way doing direct work towards that goal.

detaro 3y ago

Not just German ones... Generally, for a long time they treated components with software the same as any other component: You buy it as a standalone thing from your suppliers, who make it according to your specifications, e.g. lots of the electronics would come from a "tier-1" like Bosch, who many cases farm out making of different parts to their suppliers, who then contract bits from subsubcontractors, ... and in the end everything gets plugged together. The car maker at the top of the pyramid is giving some goals/designs and tests if everything fits together and shouts down the chain if it doesn't. And for physical parts and contained software that does kind of work. It involves a lot of specification writing and -checking, but that's what mech eng orgs are good at. A simple digital instrument cluster isn't that different from an analogue one in that regard, in the end it is "hardware has to have this shape, fulfill this spec, display has to read the following CAN signals to show what's needed". Similarly for a navigation system or software on a engine control unit. Where exactly the lines between what was done in-house and what is contracted fell varied (e.g. some at least nominally controlled the software platform for e.g. the navigation/entertainment unit themselves, others bought that too from the Tier-1 and ordered design customization as needed), but in general the car company is mostly doing "managing" and coordination. But this has a bunch of downsides: If you don't have the expertise in-house, you are beholden to what your suppliers can or are willing to do. If they do bad work, you can shout at them (and car manufacturers are quite good at shouting at suppliers), but you can't fix or potentially not even properly evaluate it. Integration across subcontractor trees is difficult to make work well and leads to even more spec-writing and shifting blame if it doesn't go well. Since the tier-1 is probably also not a software company, the software expertise is somewhere deep down the contractor tree and not properly involved with the high-level decisions. E.g. a common complaint is why the UI in cars is so sluggish: What do you expect if the people deciding about the hardware didn't have trustworthy input from people actually building the software and the software is a hodge-podge from multiple suppliers forced to work against interfaces one supplier made up without concern if its useful for the others... or even pass rudimentary common-sense tests. It also gets way worse the more integrated things become. E.g. if you have a separate box for the navigation system (in some cars it's literally a box somewhere you can take out and replace if you get a map upgrade, which gets power and a screen connector from the car), there's little to no software integration needed. In a modern fancy-ish car, the expectation is obviously that this is all integrated in one UI, the navigation can appear in the instrument cluster, map updates should probably be online and not require bringing the car to a dealer, you want one central computer instead of multiple small ones, ... So to stop all this falling apart, someone needs to own it. The Tier-1 could, but it also doesn't have a clue how and the manufacturers obviously don't want to give those more power, so they try to bring it in-house. But if you've never had a internal culture for software to grow this from, it is really hard to do that. VW specifically said they'd do it by force, with plans to hire thousands of software people over a few years to build a totally new software division that would own the entire stack from scratch. It's going about as well as one would think something like that would go... Other manufacturers who noticed this earlier and let it grow slowly are faring better. Some had more experimental "labs" divisions which were closer to the software world, whose expertise now can be used. Some have accepted they have to farm some of it out and e.g. adopt Android Automotive, even though the industry was very hesitant about that initially (because it gives Google all that juicy user data and ownership over the connectivity services the industry really would rather control itself).

konschubert 3y ago

> Structural software impacts both operation of the vehicle as well as “infotainment”. From my limited insight, it seems that they are tightly coupling these two together: operational embedded code and the infotainment layer. So they cannot roll out a UX update without also updating the embedded code that steers the vents.