Japanese Auto Makers Teaming Up To Create Standard OS 266
CNet is reporting that Japanese car manufacturers are teaming up to develop a standard automotive operating system. "Just as computer operating systems [...] allow multiple applications to communicate with one another, an automotive operating system enables different driving systems to work together. The standard automotive operating system from Japan will include everything from fuel injection, brakes and power steering to power windows. Currently, certain mechanical car parts are interchangeable from model to model. Smart car parts that operate off a common software standard would enable that kind of convenience to continue, while allowing them to communicate more easily with other smart components in a car."
I thought this was what TRON was for? (Score:5, Informative)
http://www.tron.org/index-e.html [tron.org]
Or is this an extension to TRON? (The article is really slim), though it seems to be about OSEK:
http://www.osek-vdx.org/ [osek-vdx.org]
William
Re:Oh, yeah, I love the idea of an OS on my car. (Score:5, Informative)
Currently? (Score:5, Informative)
Currently? Back in my teens, in the 80s, I hung out with a family that built street machines. There used to be this company called GMC and it had others called Chevrolet and Pontiac, et al. We could take a bell housing off a 66 Pontiac whatever and fit it perfectly to a 68 Chevrolet whatever. ALL water thermostat housings between all of these makes were the same. I can remember helping my dad with his 69 Ford Bronco to replace a cracked thermostat housing, and when we went to the junkyard the dude pulls out a huge box of ford thermostat housings -- even between Ford cars they were different. You could fit a Nova front-end to a Ventura and all the bolts matched. Anyone toying around with American cars from the 60s learned to love the GMs, especially Chevys....
GMCs, and especially Chevys, from the 60s, were God's gift to cars and auto mechanics and it was all interchangeable. Couple this with the raw power of those cars (yes yes, environment concerns and all that) and those are some of the best memories of my life....
Hehe, currently.... Reminds me of my daughter saying, "way back in the 90s...."
Could make a better OBD2 (Score:3, Informative)
Re:OSEK and AUTOSAR (Score:3, Informative)
Re:Oblig. (Score:2, Informative)
Re:offering Compatibility? (Score:2, Informative)
Re:A day late and a dollar short... (Score:4, Informative)
This means that the newer ECUs have a throttle command which is part of a message packet transmitted over a bus rather than a mechanical push/pull cable controlling the throttle lever on an engine. Even the engines that still have throttle levers aren't mechanical anymore, the lever is connected to a potentiometer which then converts the lever position into an analog signal which feeds into the ECU.
Its the natural progression that distributed systems again become more consolidated. Remember that this network inside your car is going to be electrically isolated from other systems. The likelihood of anyone hacking your car without physical access to the microcontrollers is slim to none. Unless they do something stupid like try to network this OS with outside systems which aren't wired to it.
Re:A day late and a dollar short... (Score:1, Informative)
http://en.wikipedia.org/wiki/Mercedes_(car) [wikipedia.org]
Deja Vu... (Score:2, Informative)
Real-time, also. (Score:3, Informative)
I mean, sure, there are plenty of so-called "real-time" applications that these OSes work perfectly well for. Audio, for instance -- Protools, Ardour, etc. But it's a bit like Java -- while on average, you know how long something is going to take to process, you don't have any guarantees. (In Java's case, the garbage collector might decide to run at exactly the moment you need something important to happen.)
"real-time" means that you can actually guarantee, often with mathematical proofs, that a given thing will happen by a given deadline, and usually the deadlines are much shorter than anything a modern desktop OS can handle. It means you can say things like "If the sensor reads foo, I need a shutdown command sent to the nuclear reactor within 20 milliseconds." Done properly, you can actually guarantee beyond a shadow of a doubt that this will happen -- and in 20 milliseconds, not 21. On a desktop OS, there's just no guarantee -- for all you know, a filesystem driver, of all things, could lock the whole IO system up for half a second.
That's not to say that you can't make Linux realtime -- there are projects to do so. It's also not to say that you can't build a desktop out of a realtime OS. But right now, as far as I know, there are no real-time OSes which are used for anything other than embedded apps which actually need the real-time capability.
Re:Yeah? (Score:1, Informative)
Re:Yeah? (Score:2, Informative)