If your program is hello world complexity then it isn't worth the cost to make it reusable, just write and maintain 100 different copies - meanwhile elsewhere there are only 5 copies of the transmission controls and since it is only 5 it didn't get to the top of the list to fix redundancy - but those controls are very complex and making one version would be well wroth the effort.
"AUTOSAR is a good idea, it works in theory", nope, much like communism if your theory does not work and continues to fall flat on its face it is a terrible theory. No one would say a theory of gravity that predicted you would turn into a unicorn if your really wanted to and dropped a ball at the same time had merits.
Here is an idea to make the automotive industry slightly better, just an incremental improvement. DBC files are used to specify CAN interfaces, they allow big endian and little endian messages within THE SAME MESSAGE, which is madness. Why not pick an endianess, just one, it does not matter which, do not make things generic (I have nightmares of German mechanical engineers writing software saying the word "generic"). Do that an you have actually achieved something. I am not even suggesting specifying what messages numbers do what, or what signals they contain for a particular ECU (which would make literal components reusable). The automotive industry is riddled with bad, terrible, software.
I do not know how you blame consultants, the German automotive industry sabotaged themselves.
I have no idea how it can be used in safety critical software, because no one understands it. I guess they just test the fuck out of it.
Sorry for the poorly thought out rant...AUTOSAR makes me...emotional.
I agree with your point about incremental improvements. And I agree that reducing useless options would improve the status quo.
I will have to take your word on seeing projects worse than AUTOSAR ones, I have seen terrible non-AUTOSAR projects, but the only good projects I have ever seen in the automotive industry have been non-AUTOSAR ones.
As the other commenter said AUTOSAR had some good ideas, but now it has too much cruft and it's hard to decrusity it. If they trimmed 80% of the standard, had an actual open source reference implementation, overhauled the tooling to make it not suck and added solid observability capabilities and did something about the god awful RTE experience, it would be pretty good. The API's are sane, interactions make sense.
If the car sells, it is priced at what the customer feels is reasonable. It is not for you to moan as you disagree.
And before the Chinese, there were the Koreans and others who came challenging so it's never been for easy.
I am objectively speaking, I only buy used cars after the major depreciation has happened.
But it doesn't[1]. And people agree, the main reason is: the cars (esp. the lower price ranges) are too expensive.
[1] https://www.politico.eu/article/brutal-financial-results-vol...
I'd like to see some insight on whether this has a realistic chance of being the winning bet within the companies involved. So far it sounds too obviously useful to win the politics game.
The chinese can create good looking and useful UIs and they can even go deeper in the stack.
cheap electronics will stand up to use in a car for years - something the fastest computers often fail at. I'm under NDA so I can't give more details.
Those cheap often boot instantly while more powerful ones often need a minute by the time everything is initialized.
If in doubt take a look at what they're referring to: https://eclipse-score.github.io/
Again, the platforms are all American but Europeans know how to make kick ass games that are delightful and awe inspiring. French, Polish, Ukrainians, Bulgarians, so many legendary people are from Europe.
They should hire game developer to guide the user experience and listen to them very carefully.
Meanwhile, a lot of the higher value work such as in Engines tends to pay pretty high - for example, Epic Games pays SWEs and PMs in the $200-400K TC range, but this is overwhelmingly in the US. Similar story with Unity despite originally being European, but shifting to the US in the 2000s.
music
movies
microcode (software)
high-speed pizza delivery
Now they push projects like OpenDesk[1] to fully replace MS Office (365) and OpenCode[2] where they open-source all software that is build with public money.
In my view, this has led to the German economy having more confidence in open source, and that open source can be used and maintained as a model for software over a period of 5-10 or even more years. Instead of buying licences and hoping that the manufacturers will maintain the software for at least 5 years and provide updates. In addition, there is the realisation, not least as a result of the change in the law and the current global political situation, that sovereignty is a very important factor.
[1] https://www.opendesk.eu/en
[2] https://opencode.de/en && https://gitlab.opencode.de/explore
It says all the right words and has a flashy landing page, but doesn't seem very open or impressive; am I wrong in my assessment?
What is the not-open source software used in OpenDesk? Because your example: cryptepad[2] is GNU Affero General Public License. And diagrams.net might look similar, but also LibreOffice looks similar to MS office.
Ew. I want more buttons and less software but better (most car software, visable to the user at least, is junk).
The Chinese car firms are coming for them, so they are banding together.
2. The German car industry already successfully teamed up on sharing map data (https://www.here.com/).
3. However, while this may work for Libre Office installs in a city administration and (non-critical) car infotainment software, this likely cannot work for the most important automotive control software, due to the legal responsibility of the car manufacturer (they would need to review/audit all changes of open source contributors line by line, patch by patch) - because bugs can cost lives there.
And anyways, merely auditing I serious doubt would be effective. (LGTM, ship it!)
Your engine control, your ABS and your traction control all run software (or "firmware", whatever that word means in this age) and they have been for decades.
What needs to stop is that awful trend tesla started where they replace the entire dashboard with a tablet.
You're going to have software for a modern, efficient car, whether you like it or not. For the engine (fuel injection alone needs a bunch of software), ABS, traction control, A/C, and countless other things. And whether your radio has physical buttons or not, unless that physical button is on a radio from the 1980s and directly controls a variable capacitor and a belt to a frequency indicator, it's going to have software.
Of course we had cars entirely without software, about 50 years ago. But they were slow, had many quirks, and absolutely massive relative fuel consumption compared to today.
I think this nomenclature is a result of the post-Jobs software as "app" paradigm + Web as the definitive "application" platform era.
The majority of software written, especially in these circles, is going to be some sort of user interface/CRUD stuff. The "invisible" (and frankly remarkable, when talking of things like ECUs and ABS software) is basically like The Earth (it's just always been there and taken for granted).
1) They don't want to invest in building vehicle software ecosystems as it's expensive, time consuming, and not exactly in their wheel house. Wireless and cloud connectivity just aren't their language.
2) They don't want to work with existing proprietary off the shelf ecosystem solutions -- they feel that because it's "their vehicles" they should "own" the technology and IP. They don't want vendor lock in, so they avoid existing proprietary solutions they can't "take over". And by "take over" I mean "have the vendor give their proprietary stack to them for free, so they can then share it with their other suppliers".
3) They expect the vendor base to "partner" to develop "open" software stacks for free -- which most vendors aren't keen on doing as there is little upside for the vendor to spend their own internal NRE building a system that their competitors benefit from and can quickly undercut them on. They generally refuse to pay for the development of a stack that they can own and build upon.
The root cause seems to be magical thinking from the higher ups - "Hey connectivity stuff is everywhere, it can't be hard, why should we pay for this?"
They don't want to build it. They don't see the value in paying for it. So of course open source is the obvious solution. Hey, just have the nerds build it! They love doing that kind of work for free.
Traditional RTOS' are for the most basic, safety critical functionality because the cost of certified (and even QM) code is so high and the tools available are so primitive.
Then came the software. The amount of complexity and jargon and issues and roadblocks that come out of nowhere is extraordinary. You have to dive several layers deep in a menu system to do step 1, then get hung up on opening a "gateway", then dive down the same menu to do step 2 of a 2-step process. He had another problem that kept him busy but what impressed me is the amount of time and complexity to do the simplest things. He wasn't performing many steps, but just getting to the step required rebooting, waiting, pressing the brake pedal to see when it was time to move the right turn signal stalk, didn't work, go back, do something else for 10 minutes, try again, it seemed endless.
German automotive companies have historically been terrible at software. Just because Tesla hasn't simplified or integrated their various software components yet, doesn't mean others can't do it nicer. But any company that doesn't value software like the Americans do is going to have a real tough time with the EV software problem.
After all, your craptacular pipeline was surely the secret sauce that made you get jobs and/or be cost effective while everyone else was definitely cooking with water ...
I remember a friend of mine getting openly mocked at a pub in Soho, in 2007, by his co-workers from MPC for suggesting this. DNeg, the company I worked for at the time, wasn't any better.
Mind you, this was after ILM already open-sourced OpenEXR and Alembic formats years ago and they had become industry standards more or less over night, afterwards.
Now there is the Academy Software Foundation and everyone in VFX is using OSS (that came from various big studios, mostly) all over the place.
When I worked in the automotive software industry in Germany, half a decade ago, it was the same. People shook their heads at me and I was mocked for suggesting this.
But I actually made a bet then (just a crate of beers, but hey) with one of the mockers. I guess it will soon be time to cash in on that.
Ok, being the German automotive industry (or rather: BMW & Mercedes, for now, if I read the press release right) -- when it comes to anything software it could still be anywhere between 1--5 years, before the intent "materializes" ...
ognarb•7h ago
It's a smart move to do so instead of switching to Android Auto and loosing control of one of the most important component of the experience of the car.
danogentili•6h ago
Bluestein•6h ago
greenavocado•5h ago
okanat•4h ago
bluGill•4h ago
bigfatkitten•4h ago
moogly•1h ago
eurleif•6h ago
gerdesj•4h ago
Me too - its fine for me. You are probably holding it wrong 8)
My car (Seic MG4 - an EV) clearly has two lots of software. The reliable stuff that runs the "must work" stuff like driving controls and motors etc. and the other stuff that ought to work in an ideal world and I think that lot is on the Android tablet mid dashboard.
The other stuff even includes "lane assist" and other safety features because when I force re-boot the console they report as offline on the display behind the steering wheel, which I think is linked to the first system - the RTOS automotive jobbie.
I think SEIC (and I'm sure this is standard practice) have done a fairly decent job with the divvy up of responsibility between funky features and must work or death will ensure features. I'm an IT consultant and know when Android auto has crashed on my phone or car or both or the radio is on silent or there is dust in a USB port ...
Wayland vs X11 is not an issue in cars - whatever you get will either work always or be a bit of a mild distraction.
Cheers Jon
PS I went to school in Abingdon, Oxfordshire. My car has nothing in common with the real Morris Garage. The MG marque is merely an affectation and I don't know why Seic really bothers.
bigyabai•7m ago
If you're only using a Wayland compositor to render a webview, you cut out a lot of the surface area that could potentially cause a crash.