Slashdot Mirror
When Appliances Revolt
conaone writes "From the "disconcerting" file, Baseline has a weird story about how the increase in use of embedded operating systems is causing strange things to happen to consumer products. Their example is the use of Windows CE in the BMW 745i, which apparently occasionally goes nuts. The best is the list of video clips showing off the possessed car."
I'm gonna wait to buy until BMW 745i SP 1 comes out.
:)
Does 745i come with "windows update"?
Anybody want some toast? No? So, you're a muffin man then?
Boy, if that isn't a case for Open Source, I really do not know what it.
"Don't mind me cutting myself on Occam's Razor"
In an attempt to sidestep the "Windows + (vehicle) = crash LOLOL!!!!111!!one" line of comments, which I'm sure there will be many of, I'd like to ask why you need an "embedded operating system" to begin with.
What is so preferable to this approach than more traditional imbedded computer systems? Does the functionality of the system really outweigh the overhead of an entire OS/computer system? Are they really doing anything a halfway decent microcontroller unit can't handle?
Maybe the developers are just too lazy to build their systems "from scratch" like they used to. I personally can't see the benefit of using an embedded OS. What am I missing?
=Smidge=
One day we'll see people like Steve Irwin making careers out of dealing with rogue appliances.
Amazing magic tricks
Imagine it shifting from 5th to reverse on the autobahn. "Invalid page fault" followed by "fatal exception" followed by "Missing or Damaged Passengers."
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
You've got it all wrong. These are features:
Crazy Trunk: The guy's Windows CE embedded device causes the brake lights (right side) on the trunk to flash at odd intervals. The device is in the rear passenger's right side.
This is Microsoft(tm) Active Saftey(tm) function, which alerts other drivers to the fact that you may be interfering with a Microsoft product and therefore putting your life at risk.
Spitn' Key: The guy inserts his key into the car, lets go, and it falls out for no reason about three seconds later.
This is Microsoft(tm) Trusted Commuting(tm) Initiative functionality. The car detects unauthorised use of the car maker's intellectual property and prevents the driver from taking any unauthorised action. A licence to use the car can be downloaded from the internet.
Phone Dead: The driver's car phone suddenly stops working about 5 seconds after the Windows CE device is powered on.
This is Microsoft(tm) Dial Save(tm) which saves you money on mobile and long distance calls.
Transmission: This is scary. His car goes from 4th down to 1st gear (auto transmission car) and he nearly gets rear-ended by the SUV behind him
This is Microsoft(tm) Active Compression Braking(tm) which automatically detects the drivers desire to brake suddenly and shifts down several gears to make the whole process effortless.
Microsoft - We'll Decide Where You Go Today(tm)
Reliable, Great Value Hosting: $7.95/mo 2.4G/120G
Ok, having the worked with many Real time OS's and embedded OS's... what I want to know is why the hell do they need Windows? It's bloated, the interface is not suitable for a driver (as in car driver)...
:P ) Stick to a modified version of Linux. I don't recall the exact build name, but there is a mod (or more than one) out there that make Linux practically realtime... and that's all you need for these gizmos... operating a phone, changing seat positions, etc... There you go... cheap, damned reliable (be it stripped down linux, or some other RTOS), no crap to mess up the functionality, since the only thing in the code is the bare minimum OS and drivers to control the devices you need to control (nothing more, nothing less), and a simple UI.
Develop your own RTOS... hell, grab any simple Real Time OS, be it VxWorks for example, add a display driver and an input driver (which can be developed at a very reasonable cost (Take a look at what the military uses..) Then from there add routines to communicate with your 70 or so embedded processors and voila, a stable, easy to maintain, not full of useless crap, system. Don't want to invest in an RTOS? (They can be pricey...
Ok... Someone care to tell me how much Microsoft paid to get BMW to use their WinCE for something that it clearly is not good for? Dealing with lots of unique and independent devices is not Microsoft's strong suit. To get WinCE to be reliable (as the previous poster put it), you would need to strip it to nothing more than a damned memory manager and a Task scheduler, and write custom drivers for EVERYTHING. Why bother? It's easier to start with just a bare bones OS. There are SOOOOO many other, BETTER, choices out there... There had to be one hell of a good bribe on Microsoft's part... Either that, or some dumbass making decisions at BMW don't know dick all about embedded device programming...
That's my $0.02... And no, I'm not a microsoft hater... I just don't agree with what WinCE is meant to be used for...
---
Programming is like sex... Make one mistake and support it the rest of your life.
Once upon a time, in a kingdom not far from here, a king summoned two of his advisors for a test. He showed them both a shiny metal box with two slots in the top, a control knob, and a lever. "What do you think this is?"
One advisor, an engineer, answered first. "It is a toaster," he said. The king asked, "How would you design an embedded computer for it?" The engineer replied, "Using a four-bit microcontroller, I would write a simple program that reads the darkness knob and quantizes its position to one of 16 shades of darkness, from snow white to coal black. The program would use that darkness level as the index to a 16-element table of initial timer values. Then it would turn on the heating elements and start the timer with the initial value selected from the table. At the end of the time delay, it would turn off the heat and pop up the toast. Come back next week, and I'll show you a working prototype."
The second advisor, a computer scientist, immediately recognized the danger of such short-sighted thinking. He said, "Toasters don't just turn bread into toast, they are also used to warm frozen waffles. What you see before you is really a breakfast food cooker. As the subjects of your kingdom become more sophisticated, they will demand more capabilities. They will need a breakfast food cooker that can also cook sausage, fry bacon, and make scrambled eggs. A toaster that only makes toast will soon be obsolete. If we don't look to the future, we will have to completely redesign the toaster in just a few years."
"With this in mind, we can formulate a more intelligent solution to the problem. First, create a class of breakfast foods. Specialize this class into subclasses: grains, pork, and poultry. The specialization process should be repeated with grains divided into toast, muffins, pancakes, and waffles; pork divided into sausage, links, and bacon; and poultry divided into scrambled eggs, hard- boiled eggs, poached eggs, fried eggs, and various omelet classes."
"The ham and cheese omelet class is worth special attention because it must inherit characteristics from the pork, dairy, and poultry classes. Thus, we see that the problem cannot be properly solved without multiple inheritance. At run time, the program must create the proper object and send a message to the object that says, 'Cook yourself.' The semantics of this message depend, of course, on the kind of object, so they have a different meaning to a piece of toast than to scrambled eggs."
"Reviewing the process so far, we see that the analysis phase has revealed that the primary requirement is to cook any kind of breakfast food. In the design phase, we have discovered some derived requirements. Specifically, we need an object-oriented language with multiple inheritance. Of course, users don't want the eggs to get cold while the bacon is frying, so concurrent processing is required, too."
"We must not forget the user interface. The lever that lowers the food lacks versatility, and the darkness knob is confusing. Users won't buy the product unless it has a user-friendly, graphical interface. When the breakfast cooker is plugged in, users should see a cowboy boot on the screen. Users click on it, and the message 'Booting UNIX v.8.3' appears on the screen. (UNIX 8.3 should be out by the time the product gets to the market.) Users can pull down a menu and click on the foods they want to cook."
"Having made the wise decision of specifying the software first in the design phase, all that remains is to pick an adequate hardware platform for the implementation phase. An Intel 80386 with 8MB of memory, a 30MB hard disk, and a VGA monitor should be sufficient. If you select a multitasking, object oriented language that supports multiple inheritance and has a built-in GUI, writing the program will be a snap. (Imagine the difficulty we would have had if we had foolishly allowed a hardware-first design strategy to lock us into a four-bit microcontroller!)."
The king wisely had the computer scientist beheaded, and they all lived happily ever after.
Yeah, I guess the obvious Slashdot solution would be "use Linux on the car!" Then we'd have to install a little keyboard to do stuff like this:
/sbin/unlock /dev/trunk
dd if=/dev/gastank of=/dev/engine bs=1024k count=100
Anyway... ever think that this could be the result of shitty programmers and not the OS's fault? I.E., the functionality to do various things in an automobile are NOT built into Windows last time I checked...
I've developed under Windows CE, Windows, Palm, Unix, and 8052 microcontrollers. For reliability I would choose those "platforms" in reverse order. And, yes, development tools, memory optimization, and watchdogs are available for all of them.
OS's are generally for when a single piece of hardware is going to have to do many different tasks. Maybe one user will use it to listen to music, another to burn CDs, another to develop software, another to surf the Internet, etc. Parts inside washing machines and cars, however, are not going to see such variable usage. A washing machine is always going to wash utensils. A car is always going to drive down the road. These are not applications that really require an OS. Some good firmware is all you need.
Using microcontrollers in cars is not new. They've been doing it for over a decade. Only now, when you start contaminating things with OS's such as CE, do you really see a problem.
That's what it would cost you, after dealer mark-up. A "computer" in a car is normally a "microcontroller," a single chip. So what they're really telling you is that it would cost $10k for 6 chips. And I can assure you that the unit cost of those 6 chips is under a dollar a piece.
If you can cut down the number of computers needed, you can lower the price of your car or increase the profit margin. Or both.
Increase profit margin, if that's possible. Are you really serious when you say they'd charge you $10k to replace the "6 computers" in your car???
The down side to that is that if the single computer fails, all those functions go away.
The problem is when you use OS's like CE it is entirely possible that the single computer will fail. When you develop it all on a microcontroller and get rid of all the fancy BS, you can get everything into a single chip and be stable.
You know, I really think it comes down to keeping Microsoft as far away from anything of any importance. And I say that in all honesty, not just to score points with the anti-MS crowd here.
It's a good question, and one automotive developers haven't really had to worry about until recently. When all they had to code was realtime control code for those 70-odd microcontrollers, they certainly didn't need an OS.
But the developers (or rather their marketing departments) have bigger ideas. A car is no longer but a conveyance - it's an environment, an entertainment centre, a home. So they mandate navigation, remote and stored diagnostics, centralised control of various settings (A/C, seat position, etc.), radio stations, RDS, CD control, media (MP3 etc.), radio, video (disney for the kids), and all of this controlled by voice input and giving voice output. Those are requirements a workstation or PC could scarely manage five years ago. Add to that the significant issue that most of those applications will be coming from third party vendors. Anyone implementing such a system has little choice but to put in a decent 32 bit microprocessor, a fair chunk of RAM (several meg, going on 16), and a half-decent OS.
WinCE (for automotive, whatever...) is certainly the worst choice. QNX, VxWorksAE, or Embedded(orRT)Linux would certainly be better - but the fundamental problem remains - this is HARD to get right.
Don't be fooled into thinking this is just an amusing diversion, where the worst that can happen is that your radio doesn't work for a while. This is a major safety issue - simply because the "infotainment system" doesn't have a wire to the steering or the accelerator doesn't mean it can't kill you. Imagine you're driving through a busy freeway intersection, at high speed in pretty heavy traffic. Suddenly the radio turns on, to a bad (noisy) channel, at FULL VOLUME. IT HURTS. YOU'RE SURPRISED. YOU LOSE CONCENTRATION FOR A SECOND OR TWO. YOU DIE. So do your kids, and those of the guy in the subaru in front. The lady in the dodge behind you loses a leg.
Also, don't think this is confined to high-end cars like BMW and Cadillac - auto manufacturers try out new stuff in the high-end lines before they push it further down the product line. Soon you won't be able to buy a vehicle without this stuff. And __nobody__ is doing a good job of making it.
## W.Finlay McWalter ## http://www.mcwalter.org ##
Pinning the problems on the user is really wrong in this case. This system was destined to fail. The only one that i've tried that was worse was in the Buick Reatta. (Anyone remember that?)
funny, i always thought that washing machines were for clothes; maybe i have to update the firmware on mine...
I never said I was smart, I just said I was smarter than you
It's awfully fun reading desktop programmers commenting on an article in a project management magazine.
Here's a few facts about your new-model car. The BMW is extreme with 70 electronic modules but the typical 2003 vehicle has 20 or 30 microprocessor-controlled modules, and the number is rising every year. These range from a door-switch module with 8K of code, through an engine controller with 256K/32K of ROM/RAM, to a navigation system at 8M/8M. Very few of these modules have a manufacturing cost above $100.
The OS in automotive controllers varies from a simple event loop at the low end through OSEK-compliant kernels in the midrange to QNX and its friends in the most complicated systems. If there's Linux in a controller, it will be as well-hidden as the Linux in Tivo. Engine and transmission controllers are designed for hard real-time operation and emphatically do not use anything remotely resembling a desktop or palmtop OS.
Software development starts with the premise that once it's built, you can't change the it, ever. This has enormous consequences for the way automotive code gets made. Most companies spec the hell out of these products, use a strict waterfall development process, are afraid to venture beyond the C language, and test endlessly. They are scared of agile methodologies and even of RUP. Productivity is pretty low, but on the other hand, the products are reliable.
Now, both the article and /. responses are full of misconceptions. There's not really much question about whether an OS vendor shares its source code. The real concern is reliability. There's not much question about who develops embedded software. Detroit is lousy with contractors. One billboard I see on my commute shows a toy car with the caption "about the only vehicle that doesn't run on our software. -- EDS" The GM guy's comment about 10 year old software has the obvious answer: his teenager's 1993 Chevy.
Win CE gets no respect from embedded software developers for several reasons. Chief among them are poor responsiveness, poor stability and code bloat. Typical comment, from an SAE conference presenter: "If you put an embedded system into a car, you still have a car. If you put a PC into a car, you have a PC with wheels."
Rather than rant any further, let me suggest reading any of the books on Jean Labrosse's site, EE Times and Embedded Systems Programming. And have fun! Embedded is where you can see software affect the real world.