Choosing an Embedded OS for Sustainability?

vivekb asks: "I work for a small start-up that's building its first commercial product. Because cost is less of an issue than development time, we've decided to make the brains out of an ETX computer with some sort of (non-realtime) operating system. Based on initial costs of tools and estimated license fees, the cheapest OS's I've found are Windows CE and several offerings of Linux. The big question that I can't answer is, 'How much will these platforms cost in sustaining activities?' In three years, when we're fixing bugs or applying patches, how much will we be paying vendors and how much will we be spending on internal developers? When the Linux kernel is at version 3.0 and our device is still running 2.6 -- or when CE reaches .INFO and we're still at .NET -- will support even be available? If anyone has past experience picking an embedded OS for a screen-and-button based electronic device, what did you learn to stick with or avoid?"

Hmm..

[Anonymous Coward]

Well, one viable OS the author of the article is forgetting about are the BSD variants, specifically NetBSD if you're wanting to use it on an embedded device. Many people have been using netbsd on various devices, which even NetBSD supporting suspend on some. I believe the author needs to take a look at what he is really wanting however. Money is the main goal in any project. Please take some time to think, "what is the easiest and best way to deploy while making a profit?"

Tsume

Linux for Longevity.

[Deathlizard]

If longevity is the #1 issue for your app, then your best bet in the long run is Linux simply because the kernel source code is available to you and can be customized to work exactly and naively for your application. Even if a kernel update comes out, it shouldn't be too hard to upgrade to it since the source code is available to make migrating to the newer kernel easier.

Keep in mind, that if code security is an issue, Linux may not be an answer since any kernel changes has to be available for public use. If no kernel changes have to be made for your app however, I don't think it would be a problem however IANAL. Other people here could answer this question a lot better than I could.

Device Drivers

[bsd4me]

I would pick the OS based on whichever has the best device driver support for everything in your product. Device driver development can chew up a lot of time. You would be better off spending resource time on the application layer of the product.

Source code

[sunderland56]

If you really want it to be sustainable, use something where you have access to the source code. Even if you don't want to modify the sources, just having access can help you track down obscure bugs.

So of the two you've listed, clearly Linux would be your choice. Plus, don't forget that Microsoft's embedded OSes reinvent themselves every few years - just wait until they throw out CE and sell you Vista Embedded next year.

There are other choices based on the size/scale of your project - such as Nucleus, which gives you source access.

Figure out your requirements first

[ifdef]

I've worked on products that had no OS at all, just a loop that called various functions in sequence. I've worked on products where the company wrote the realtime OS from scratch. I've worked on products where the company used a commercial OS, but bought a source code licence. I've worked on products which used an off-the-shelf Microsoft OS. It all depends on your requirements.

Are there realtime requirements? Do you know what hardware will be used, or will you need to support different kinds of displays, for example? What are the reliability requirements -- will this be used in life-critical applications, or will it be used for games? Will you want to upgrade to the latest version of the OS from time to time, or will you pick a good one and make zillions of copies of your product based on that one version? I'm sure there are other questions you should be asking yourself (help me, fellow Slashdotters).

Figure out your requirements first, then figure out how to meet those requirements. Don't just pick a solution and then try to make it fit.

Not a problem which should be solved

[dslamguy]

I have been developing embedded systems for over 20 years and I have never seen the need to upgrade the OS. Never! The beauty of an embedded system is that the user does not see the OS and really does not (or should not) care what it is. You are going through a development cycle and if you do your job well, you will be fixing most problems during the development cycle before the first release and immediately after. Over the years, you will be in a maintenance mode and you will only be fixing some functionality problems.

You will NEVER want to destabilize your product and have significant retesting by upgrading the Kernel or OS. Why? What new features in the OS matter to your customers? After all the OS is not your product and the customer should not care. Keep in mind that the OS vendors will be trying to get you to distribute upgrades, but resist the temptation. You will be spending money for no reason.

When you need to develop phase II of the product, its a different ball-game. Then you can use a new version of the OS, or a different OS. The point is, you are not "upgrading" your kernel, you are developing an evolution of your product on a new OS. Different mindset.

Re:Not a problem which should be solved

[Bing Tsher E]

It depends a LOT on what said embedded application is intended for.

If your embedded OS goes into a home appliance or some stand-alone application, your experience holds fast. If the application is net connected and world-visible, i.e. the controller in an internet-enabled vending machine, then your experience and opinion is lacking. It is NOT acceptable to 'screw down the lid and forget' about a net connected app, especially if a widely-used OS is embedded. Exploits WILL surface, and maintenance of the system to protect against said expoits WILL be necessary.