Anybody who knows how the auto industry ticks (as long as its clock hasn’t run out) sees the next two items as a given:
1.) Cars will be more and more crammed with electronics. Already, some modern cars have more computers and networks than a small business.
2.) Keeping track of the software and its bugs turns more and more into a nightmare.
So far, most large automakers have used their own proprietary solutions, which makes the nightmare even bigger. Many common parts cannot be fitted unless their internal software is “flashed” to be (hopefully) compatible with the car being repaired. Something’s gotta be done. And, finally, it is.
Toyota, Hitachi, Nissan, Honda, Denso, Toshiba, Panasonic, and other Japanese automakers and electrical machinery manufacturers are joining forces to develop a common software infrastructure for automobile electronic control systems by year-end, the Nikkei says. Seventy-three firms will take part in the efforts to standardize software specifications; and an additional fifty or so companies plan to adopt the standardized software.
The project is aimed at developing a software platform for automobile electronic control systems, such as those for the engine, transmission, safety mechanisms, car navigation systems and communications systems. Automakers and auto-parts producers can tweak this common software platform to add unique features.
In Europe, a group of automakers and auto-parts manufacturers (e.g., Volkswagen and the Bosch group) has already been working to develop their version of the standardized software known as the Automotive Open System Architecture, or Autosar. The Japanese group plans to draw up specifications based on Autosar to make the two platforms compatible. A common software infrastructure will help carmakers cut this by 30-50% industry analysts say.
I wonder if they’ll call it OBE-1.
Just keep Microsoft’s mitts off it please!
Despite any efforts towards standardization and open systems, at the same time each automaker doesn’t seem to want to do it. They all talk a good game at conferences but they rationalize why they can’t do it now and then they undermine the efforts.
That’s my take.
I suppose it’s too much to hope for that they’ll start with RTL?
BTW the diagram is hilarious, would like to see the whole thing.
The various engineering departments of the major automakers and top-tier suppliers have a huge case of “Not Invented Here” syndrome.
I spent a lot of time in middleware, getting various systems properly exchanging data in what passed for a seamless fashion. It’s hateful work, and vendors don’t make it easy because they have very little incentive to do so. You think IT is bad? At least we have to interoperate, even if it’s just badly enough to convince someone to use your server/client/middleware solution in lieu of the one(s) you’re trying to glue together.
Automakers? Between the liability concerns and the sheer egotism, I highly doubt it’ll ever happen.
Or worse, if it does, the implementations will be ever so slightly different as to make interoperability a nightmare (think about the amusment of dealing with different vendor’s takes CORBA or SOAP, only with more ego thrown in). Again, I fully expect the Europeans in general (and the Germans in particular) to be the worst about this: their cars already make life hell for anyone trying to use open diagnosis tools because the extra crud they’re fond of tacking onto things.
Remember how just plugging an OBD-II scanner into certain VWs will whack things? ODB-II is child’s play compared to what they’re proposing above.
Whether or not I like this depends on one thing:
CAN I REFLASH IT?
Not for nothing, but the ability to add 30hp in 15 minutes by reflashing an ECU is not something that I want to give up any time soon.
Automotive Open System Architecture. I don’t think Micro$oft will be involved…sounds too much like LINUX.
Free Beer!
BTW the diagram is hilarious, would like to see the whole thing.
There you go.
Some of the manufacturers that participate in Formula 1 are now using a common ECU as mandated by the FIA so this is nothing that their engineers should have a problem working out (BMW, Mercedes through McLaren, Toyota, Renault, Ferari, and Honda was even a part of it before they pulled out).
If memory serves the McLaren team developed the ECU with Microsoft (scary as that is) and it’s worked out ok so far.
pariah:
C3PO would like to have a word with you… :-)
ah! The Bismark vs. The Yamato. Guest appearance by Godzilla if it looks like the Yamato is losing…
Does this mean a guy in Pennsylvania won’t have to reverse engineer VW’s communication system to allow people to figure out the details about why their check engine light is on? (www.ross-tech.com). If so, that’d be awesome. But I can’t see VW doing it because it would make life too easy.
Full size version:
http://technabob.com/blog/wp-content/uploads/2008/05/geek_flow_chart_nyt.gif
Hopefully source will be provided. I’d love to customize, say, the entertainment deck.
First customization?
LCD screens in front seat don’t work if engine is on, LCD’s in back seat can work at all times.
I’m sure there are tons of other neat stuff to customize if we are given source code.
Interesting, Bertel, because Toyota is one of the core partners of Autosar, along with the Germans and Peugeot. Most of the other Japanese companies are premium members including Honda, Mazda and Nissan, along with Hyundai and Fiat. (autosar.org)
Why the split, do you think? Or is it just a case of getting on with it a bit quicker than the Europeans were doing, seeing how technical things were supposed to have been decided back in 2006.
Hey, I’ve done a lot of stuff in that chart. By lot I mean most of course.
Good idea! Now let’s hope that the “Big Brother” parts of this system (you know it’s gonna happen) can be defeated by your average Joe with a flash programmer.
@wmba: Why tiers? See http://www.autosar.org/download/conferencedocs/03_AUTOSAR_Tutorial.pdf page 12
Great idea in theory though I do worry it won’t be the utopian dream we all wish. Witness something as straightforward as Bluetooth. A standard. How many different ways did OEMs, mobile device manufacturers and 3rd parties adhere to or interpret the standards (e.g. profiles) in their own ways? End result, piss poor interoperability and ridiculous statements like, oh, only the following 9 devices are compatible with your vehicle sir, and you must have the specific firmware version noted in our 2-year old PDF document.
It’s inevitable that all this software will increasingly be part of the cars we buy today and in the future. I don’t like it. I still shake my head remembering the experiences my former manager had with his then brand new E60 M5 (in 2006). Every week he was at the dealer having new software versions installed. So much for the ultimate driving machine, more like the unreliable computing machine.
I want my cars to be mechanical, a joy manipulating it on the open windy roads, the aural experience of an engine and exhaust note, the click-clack engaging of gears, the smell of hot brakes and sumptuous design lines that bring a smile. Is that so much to ask?
I’d pay an extra couple of grand for a car with an Apple OS.
Neither AUTOSAR or JASPAR are an O/S.
Think of them as a set of rules. Currently, different OEM’s have different rules as to how their version of CAN works (See FNOS, GMLAN, etc).
Moving to FlexRay, many people saw the need to standardize the rules so that if you have a module that works for OEM A, you can provide it to OEM B without changing the core SW. This saves money for the OEM’s (don’t have to pay for custom core SW for an existing module) and the suppliers, who can provide the same module package with minimal changes to the application layer only. AUTOSAR is also being implemented for CAN, as it is not going away anytime soon.
Nice idea, but already we are seeing deviations from AUTOSAR by some of the German OEM’s and as with any organization that has multiple partners, there are some additional components of AUTOSAR that need to be defined, but some of the core partners don’t want to play nice and agree to implement these additions. It will be an ongoing effort for some time.
A huge component of SW cost is diagnostics – the new trend is to go to UDS (universal diagnostics services) which would circumvent the various OEM’s current diagnostics implementations to go with a standard.
All I know is that I don’t ever want to pay money for a car that has anything developed by Microsoft in it.
I need to know:
Is TTAC before or after “KHAAAN!!!” ??
Witness something as straightforward as Bluetooth
Yes.
That’s the example I was searching for before I went off into nerdland: a multivendor standard that allows just enough freedom (or vaguarity, depending on your point of view) to become an complete clusterfuck when implemented.
This would be similar, only more costly.
All I know is that I don’t ever want to pay money for a car that has anything developed by Microsoft in it.
Now, Microsoft deserves all the blame it can get for, say, the registry, or ActiveX, or Windows Mobile, but—strangely—they do hardware very, very well. I was at a demonstration and Q&A for Microsoft Surface recently and I thought it would make a wonderful ICE platform.
My first PDA and my last two cell phones used Windows Mobile. There are always things that could have been done better, but in my experience, each version has been amazingly fast, stable, and reliable.
I am a specialist in software quality assurance (20+ years), and I can tell you this is not necessarily a good development. For one thing, having a shared OS among so many disparate auto producers means, pretty much automatically, any bugs will affect a much wider range of vehicles, and their effects will cease to be localized to a single manufacturer.
Moreover, this means that any bug found in any one manufacturer context will have to be reproduced in all the others (if possible) to validate its scope. Ditto for any proposed fixes.
This could actually remove agility of diagnosis and reponse, while at the same time guaranteeing a possibly catastrophic growth in scope of those affected.
Just sayin’.
Microsoft has quite a presence in the machine tool industry. A large number of today’s modern machine tools run Microsoft WinCE and WinFlex as the graphical HMI (Human-Machine Inerface).
There are always things that could have been done better, but in my experience, each version has been amazingly fast, stable, and reliable.
Off-topic: Hard reset the device while you’re checking email. Did your email account disappear? How about your WiFi key? This is how Microsoft solved persistent storage (or the lack thereof) in WM.
Granted, they’re getting better, but wiping out databases on reset is something Palm, BlackBerry and Symbian all solved nearly a decade ago.
Windows Mobile (and thusly things like WinCE or XPe, which form the foundations of SYNC and the like) have exactly one advantage: developers. Any Windows coder can pick up WM with relative ease, which you can’t say for even decent environments (iPhone), let alone moderately tough ones (BlackBerry, Java MIDlet) or utter crap like Symbian.
Hopefully it can be hacked for performance tuning and disabling the inevitable GPS tracking the nanny state is insisting on.
Worst case scenario. The O/S is closed, and to tamper with it triggers the DMCA, the digital millenuim copyright act, which prohibits reverse engineering technology designed to protect content (this is why there is very limited recording capability for your DVR and no way to export recorded shows, and if you figured out a way to bugger the DVR, and shared the info, you could be prosecuted)
Once someone figures out how to tie this into tolling and enforcement, then tampering will be a seperate crime. Just like how no one can tamper with an odometer today (cough), this system too will be foolproof.
The O/S is closed, and to tamper with it triggers the DMCA, the digital millenuim copyright act, which prohibits reverse engineering technology designed to protect content
The nice thing about the DCMA is that it doesn’t forbid reverse-engineering unless the reason is to circumvent copy-protection. It does not forbid reverse-engineering for acaademic purposes, or for reasons of interoperability.
So, you could release something that let you read the parameters of your VW’s ECU. What you might get into trouble is if you need to use any of VW’s intellectual property to do so, or if you transposed, say, the engine tuning of an Audi making 300hp onto a VW making 200hp from the same engine.
CarPerson is correct, Microsoft already has infiltrated the industrial market with their WinCE platform. I’ve encountered it 4 times in the last 2 years where its being used as an application server for various industrial platforms. This is one hell of a stinker platform as it has ZERO (as in 0) security features built into it. The people building on these platforms have ZERO concept of security when designing their software on them or how to build a robust system.
These platforms are also susceptible to many of the malware issues that the standard Windows PC is. Just imagine that someone figures out how to hack into the Auto systems and issues a remote shutdown command through a bluetooth or wireless interface (standard on most WinCE platforms BTW) to all of the cars in a given area. Or better yet imagine going into your dealer for an oil change and being told you need to buy an anti-virus package for your auto.
Microsoft has a crap OS and if they stick it into a car it will also be crap and your life will now depend on it. Bad time to get a BSOD when you need your anti-lock brakes to kick in.
@ dew542512 — I hate to break it to you, but Microsoft has great success with their Windows Automotive and Microsoft Automotive platforms, both of which have been in the marketplace for many years. Take your MS-phobia elsewhere. No one who knows anything about how these systems work will buy the BSOD “my brakes don’t work” BS.
Take your MS-phobia elsewhere.
I agree, even if I’m not Microsoft’s biggest fan. In a car, the hardware is largely “the same”. That is, Driver A will not be adding an nVidia card while Driver B has gone with an ATI Radeon. One of Windows’ main problems is that it has to deal with all kinds of different hardware and software AND users. Methinks that the closed auto environment means a much more stable OS.
If Scuderia Ferrari can live with a Microsoft-developed ECU, I think we can as well.
FWIW, iDrive has been Windows CE-based since the outset, I believe, while Audi’s MMI is based on some RTL variant or QNX.
Microsoft is a very big company and they do some things amazingly poorly (“server” operating systems) and others very well (SYNC). Different people, different cultures, different rules.
With that said, if I understand what some of the other contributors are saying, this is like POSIX — a “standard” to be implemented however somebody feels like implementing it.
@ Jack Baruth — FWIW, I’m pretty sure that iDrive was only using a WinCE-based solution for it’s introductory year and that it’s actually migrated across a couple of different platforms since (e.g., VxWorks).
If it has to be anything, OS-9 please.
Besides that one, operating systems are for wimps.