Slashdot Mirror
Open Source In Embedded Systems
coxjohnson writes: "Technology Review reports on the OS battle between Microsoft and Open Source for the lucrative embedded computing market. Since 99% of computers can be found in embedded applications, an Open Source victory in this sector could deal a major blow to Microsoft." Good informative overview of the competition for embedded OSes.
There are things which do benefit from intelligence, especially things that control other things. IBM and Carrier are collaborating on an airconditioner which is controllable through HTTP and HTML forms. In a commercial environment, if there was a blackout and you switched to your emergency generators, the facilities manager could turn down noncritical airconditioners to conserve power. If you were going to be working late you could use your WAP phone to tell the air conditioner to turn on a few hours later. This seems frivolous, but if energy prices go high enough there'll be people in CA willing to pay the premium.
I'll give you one appliance I have that is fairly intelligent. My thermostat has a PIC that adapts based on the way my house responds. I tell it to keep the house at 58 degrees all night, and then to bump it up to 68 at 7 am (it then turns it back down after 8:30 AM). Initially, it just turns on the heat at 7am, but gradually, it figures out how long it takes my house to go from 58-68; if that's 20 minutes it starts the heat at 6:40 AM. As the seasons progress, it continually adapts so that it always hits the mark when I ask it to. I love this because I like it to be cold when I sleep but have trouble getting out of bed unless it is warm.
The problem is that it is painfully hard to program. I'm pretty good at this kind of stuff, but I don't look forward to figuring it out again when the battery goes dead. Think of the proliferation of bad interfaces; these are generally because some kind of complex behavior is required, but there isn't money or space for a decent UI and no computing power for connectivity to something with a reasonable UI. And, bad enough as the interface problems are on my thermostat, I'd like it to be even more complicated in behavior -- eventually I'd like a system that controlled heat and cold air to different rooms on individual schedules.
I can give other examples. Many people have systems which control irrigation on a timer. These could well get smarter as the costs go down. Why water the grass after a rain storm, or better yet, why not cut down the watering if there is 50% chance of rain today, or if it is cloudy? You may need to water the grass more when the temperatures are high. Water is likely to become fabulously expensive in places over the next few decades.
Of course, there's even MORE utility for this in an agricultural setting. I had a farmer recently ask me about web enabling some heating equipment he had for some high value crops.
Generally speaking, the consumer part of this is just the tip of the iceberg. Commercial, industrial and agricultural environments abound with things that are already smart but difficult to use, or which really ought to be smarter. Why not have an elevator service which adapted to produce minimal wait times by prepositioning the cars based on statistical analysis? Or which automatically switched some cars into express mode? For all I know new elevators are already doing this; most likely you wouldn't notice.
The degree of automation is almost incredible, and almost all of it utterly invisible to the casual observer.
For example, there is one company that sells salmon to high end restaurants. It has strategically placed several facilities within less than a day's driving distance of probably 90% of their potential US clientele. The restaurant orders exactly the number of steaks or filets in precisely the portion size they want. Meanwhile, workers throw a continuous stream of fish onto a computerized assembly line, where laser scanners develop a 3D model of a fish. This goes into a sophisticated computer model which basically figures out how to cut the stream of fish into pieces that will fit all the needed orders with minimal wastage. Robotically controlled jets of super high pressure water cut the salmon, and each piece is then routed to the container destined for the ordering restaurant.
You, as a diner, have no idea of the automation involved in the salmon steak your eating; even the chef doesn't know. All he knows is that he can order two dozen one pound salmon steaks at 10 AM and have the right number of steaks, accurate to within less than an ounce, ready for the dinner rush.
Ultimately technology like this will allow us to enjoy a higher standard of living with less environmental impact. Go capital!
Oh, and that toaster? I'd like to put my toast in at night and have it hot and ready for me after I wake up in the morning. If I didn't have to program another damned clock. It should also have a smoke detector and shutdown when my toast begins to burn.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Unless my embedded system has a GUI (e.g.: a PDA), why would I _ever_ use a Microsoft operating system? There are plenty of other good choices out there, including (as mentioned above), but not limited to, VxWorks, OSE, various BSDs, some Linux distributions, LynxOS, and a whole bunch of others.
Most of these are (by reputation) faster, more reliable, and more stable, with more embedded-type features such as real-time scheduling and cross-platform support.
Unless I need a nice GUI on my system (and I'm pretty sure GUI-based embedded applications are only a small fraction of the embedded market), I might as well go with one of these. Whether Open Source or commercial win, I don't know, but MS doesn't even seem to be a contender.
Oh, and regardless of open source, many of the commercial vendors (some mentioned above) support open standards such as POSIX, making even more interoperability possible. How about WinCE? Hmmm...
-Puk
ÕÕ
ÕÕ
Of course, a couple of other lessions learned from that job are that you should hire developers who know the platform you're using. Moving a bunch of Win* programmers with no previous Linux experience over to a Linux platform seems to be a recipe for disaster. Also, a clueless manager can spell doom for a project. Well, we knew that from before, but I've never seen a project heading for destruction quite that fast before. It was actually kind of impressive in a morbid sort of way.
Anyway, Linux can be a good choice of environment for at least some embedded projects and if it fits your needs it can save you a considerable amount of money in the process.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
As they have little market share. Linux is competing against other closed source embedded systems, most of which most of you have never heard of. Why? Because they go along and they work fine. Here's to hoping this proprietary stuff keeps going. My Microwave works great as it is. I don't want it to signal 11 on me.
You see, the embedded market is already solid. It is not a fluid entity like say, DB and web servers. The proprietary manufacturers have stuff locked up. MS has little chance to be a big player. Linux has some being a Unix, but it will be a proprietary Linux that even if the code is open, is of no use to anyone else. These guys are coding in languages closer to assembler, not pearl.
1. Open source. I know it's fairly obvious and has been mentioned before, but it really is a pain in the ass to get the proprietary embedded OS folks to take your project seriously. Basically you have to take what they give you and like it. Often there are workarounds, but that's more engineering time, usually for hardware, to fix a fairly simple software problem.
2. Native developement. I haven't seen this mentioned by anyone else yet, but it is a definate advantage to be able to run the same OS on the system you write the code on as you are on the embedded system. It makes testing/debugging a lot easier.
3. Licensing fees. At my last job we used Phar Lap, a unix variant embedded OS. We had to purchase a license for every single processor that running Phar Lap. These licenses came in the form of sheets of little stickers that we had to put somewhere on each board that had a processor running Phar Lap. The stickers were made from a conductive material. What a pain in the ass. On the other hand you could buy one copy of an embedded linux, or built your own embedded linux and use it as many times as you want. If you want stickers you can print up as many "Powered by YOURCOMPANYHERE Linux" stickers as you want real cheap.
4. Support (or, do you know where your copy of windows 3.1 is?). How do support a legacy system that is running a proprietary closed source OS? Tis is a real problem for embedded systems as many of them need to be supported for 5, 10 years, or more. At the afore mentioned job we supported systems for 7 years and generally at that point one of the support techs would "retire", buy up any excess parts we had for that system, and we would refer any support inquiries to them and/or their consulting company. Finding replacement hardware was hard enough, even within the 7 year window, but try finding a copy of an OS that hasn't been sold for 5 or 10 years. Go ahead, try to buy a copy of windows 3.1, I dare you...
Anyway, I spent a couple months trying to sell our engineers on linux (versus a combo of NT controlling Phar Lap or VxWorks) and some of them seemed to be interested, but of course I got laid off because of the tech slump, so I don't know if it's actually going somewhere.
Under capitalism man exploits man. Under communism it's the other way around.
How can a rational person attempt to compare the programming within a watch or toaster to that which resides in a computer system? Surely MIT is not suggesting that the two are equivalent!
What would be the simple cost of upgrading all simple household appliances to run a heavyweight Operating System such as Windows or Linux, and why would there be any benefits to doing this? Indeed, what should a toaster do besides toast? Why should a watch concern itself with anything but the time of day?
This is simply technology for the sake of technology: dangerous, and not in the best interests of the people that MIT claims to serve. It is not sane, rational, or in the best interests of mankind, and as such, is a shame to their long University tradition of developing and promoting new and useful technology.
---
Curiously, though, there seems to be something fishy, a dark side, regarding Windows Media Player, aka WMP.
WMP, the acronym, looks strangely like WhoMP, as in conquer and destroy.
WMP is strangely a high quality product--indicative of an attempt to gain "market share" in the area of music file formats. (The reason I say "market share" is because, well, is there's a market here?)
WMP has its own format while maintaining backwards compatibility.
When I installed WinAmp, clippy politely informed me that Windows Media Player had all the features of WinAmp and more. Then he (or she) politely informed me that he (or she) could uninstall WinAmp for me. At first I didn't want to, but then it did that Japanese seizure-inducing thing, foreshadowing the coming events:
When I set my computer's clock to 2002, WMP said "MP3 format has become obsolete. All your MP3 are downgrade to 56 kbps."
When I set my computer's clock to 2003, windows said, "You are not using our flagship product!!! Please upgrade to XP; it's our flagship product!!! Make your time! Small print: you do not have to do this."
Okay, this post is getting stupid, so I'm stopping now.
Got friends?
not to use Windows XP in embedded MP3 players.
Got friends?
But the car, fridge, and toaster do not need an OS and aren't getting one soon. Embedded is most of what I do, and it is mostly done to the bare metal in minimal hardware. Even when it is bloated (as when a 6-level interrupt system has been coded in C++ on a 80186) it's a charming kind of backward bloat, harkening to the 1980's. It takes 256 whole K, isn't that cu-ute.
Most embedded apps are realtime, mission critical, single-tasking (or pseudo-multitaskable), and lack user interfaces. Until recently the dominant chip in car applications was the 8048. When you are building in the quantities, with the price structure, and with the requirements of embedded, it usually makes sense to code the whole thing from the bare metal up in C and assembler.
We are beginning to see a few devices that don't really need OS's showing up with OS-like kernels, and they are notoriously slow and unreliable. They don't compete well against more traditionally created firmware, which runs circles around them even on inferior hardware. At least this is the case in the scale industry; I don't see why it would be different anywhere else. Even PC104 hasn't really taken off, despite a few companies that have invested in it. When you are building mission-critical stuff or in quantities of millions, it makes sense to do it from the ground up. In the first hand you have the chance to make sure it's right, and in the second you save money. Yes, Virginia, it does make a difference whether you need 512K RAMS instead of 256's. And the ability to live with that extra wait state can make the difference between a product that ships now and one that never does.
There simply is no room for a general-purpose OS in such an environment. We've seen them (QNX, etc.) already where they are appropriate, and that niche isn't going to change. Meanwhile, neither Linux nor anything ever created by Microsoft since 1974 is really suitable for an embedded platform.
Brackets contain world's first nanosig, highly magnified:[.]
What are Microsoft's big advantages for desktop computering, and how do they apply to embedded computing?
Add in overall OS stability (Linux beats Windows by a mile) and the ability to customize the kernel to fit your particular embedded application, and I don't see the fit of WinCE in any non-GUI embedded environment. Linux, OTOH, is a great match. I wish I'd had it when I was doing embedded realtime code and had to roll my own mini-OS.