What is the best Embedded Operating System?

R

Thread Starter

Rick Daniel

We're casting about for an embedded operating system to put into a new automation product, and I was just wondering what the collective wisdom of this list is on the matter. I'm interested in things like market acceptance, available support, technical capabilities and such. Does anyone have any strong opinions?

Thanks,

Rick Daniel

Intelligent Instrumentation
 
B

Bob Peterson

A couple of comments.

1. For the type of product you are looking at selling does the market really care what the O/S is?

2. On the market acceptance aspect you cannot beat some form of Windows. Its managed to garner nearly 100% of the market in its niches. That tells you something about its market acceptance.

3. On the support issue - guess who wins hands down? Once again, the support available for Windows is just not readily available on any other O/S.

4. On the capabilities issue - the only capabilities that matter are "can it do the job effectively and efficiently"? Sounds like an issue that is almost entirely determined by what you need the O/S to do.

I am sure that a certain person will issue a strong opinion that only Linux is suited to whatever task it is you have in mind, even without having a clue what that task might be.

My guess - if the end user has to interact extensively with the O/S, then probably you will end up with some form of Windows. If not, it probably does not matter what you use.

BTW-my personal favorite was CPM-80.

:)



Bob Peterson
 
M

Matt Warshawsky

If you are interested in using windows on your product, make sure and check out Windows NTE. It is windows designed for embedded systems. Not only can you control the install better, but you can create images of the complete operating system and then just copy them to your media without having to install windows multiple times. The license fees are also significantly less. Here are a few websites about it:

"http://www.versalogic.com/support/WhitePaper/NTE.asp":http://www.versalogic.com/support/WhitePaper/NTE.asp

"http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tdhelp40/html/overviewtd.asp
":http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tdhelp40/html/overviewtd.asp

"http://msdn.microsoft.com/library/default.asp?URL=/library/techart/preparetd.htm":http://msdn.microsoft.com/library/default.asp?URL=/library/techart/preparetd.htm

"http://www.vci.com/products/microsoft_licenses/winnt_embedded.asp":http://www.vci.com/products/microsoft_licenses/winnt_embedded.asp
 
J

James Ingraham

Saying "what's the best embedded OS?" is like saying "what's the best vehicle?"
If you're hauling lumber, get a pick-up. If you want speed you need a sports car.

For the deeply embedded stuff, WindRiver's VxWorks is probably the best. My company prefers QNX, which runs on standard PCs and therefor is a little easier to deal with. Both have wide market acceptance (QNX is used by NASA for the
International Space Station, VxWorks gets used in just about everything.) There are literally hundreds of other options.

If you don't care about real-time, Linux is widely accepted and is very easy to customize. Windows CE, Windows NT Embedded, and Windows XP Embedded are all possible choices. Wind River also sells FreeBSD for embedded non-real-time
applications. Of course, QNX can handle this just as well.

Hope that helps.

-James Ingraham
Sage Automation, Inc.

 
Market acceptance - Windows. Available support - Linux. Technical capabilities - QNX.

But that's just an initial comment; to be able to tell you anything useful, we'd have to know more about what you intend to do. What kind of support are you after? What exactly technical capabilities?

Particularly with the technical capabilities, it's much better to have a list and then match it against particular OSes than to pick an OS with generic ``best technical capabilities'' and then find out that the one capability you really need is not there.

So, as they say on the game shows - more information please.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
R
Well, I guess my description was a little sketchy, wasn't it? I'm trying to be careful not to advertise so I don't get bounced from the list!

The product we're considering is the next member of a general monitoring and control system family. It will be realtively small in size, modular, and will support a mix of analog and digital I/O. It won;t have any rotating media. It will offer Ethernet/ TCP/IP connectivity. Market acceptance of the o/s is important because the unit will run local programs developed by the end user, and we want to have ready availability of standard tools to allow him/her to accomplish this. We also want something that plenty of programmers out there know how to deal with without having to learn an obscure language or methodology.

I can't be more specific about the job we want it to do because it will be general purpose in nature.

We need an o/s that lots of people know and understand, that can be embedded in a relatively small footprint (i.e. it can't require a hard disk), that has ready availability of standard programming tools, is robust, and that has real time capabilities.

Rick Daniel
Intelligent Instrumentation
 
A

Alex Pavloff

There isn't any "one size fits all" answer to this question. What does your device do, and what are its technical specifications? Is it an embedded device that uses an Pentium III and 256megs of RAM and a 10 gig hard drive? Or is it a ARM7 with 2 megs of RAM and 256KB of flash? Or is it something smaller or bigger?

Without that information, no one has enough information to make any sort of proper recommendation.

Alex Pavloff
Software Engineer
Eason Technology
 
Rick Daniel:
> The product we're considering is the next member of a general monitoring
> and control system family.
...
> We need an o/s that lots of people know and understand, that can be
> embedded in a relatively small footprint (i.e. it can't require a hard
> disk), that has ready availability of standard programming tools, is
> robust, and that has real time capabilities.

If you need real-time capabilities, it's probably best to start your search from those, because that'll cut down the options the fastest - especially if you're after hard real-time.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
M

Michael Griffin

You wrote:
>We're casting about for an embedded operating system to put into a new
>automation product, and I was just wondering what the collective wisdom
>of this list is on the matter. I'm interested in things like market
>acceptance, available support, technical capabilities and such. Does
>anyone have any strong opinions?

I seem to have missed the beginning of this thread, but I thought I could mention a few points you may wish to think about.

First, once you start defining your requirements as being diskless and real time, you are out of the realm of typical computer systems. If the end user is to see or use the operating system, don't assume they know anything about it. For example, most people who use Windows at work or at home really know virtually nothing about it except how to click on icons. Unless you intend to totally hide the operating system from the end user (and many embedded systems do) you are going to have to provide a good user manual regardless of what operating system you use.

A second point is, if you have been considering using "Windows NT Embedded" (as was recommended by someone), you may want to think again, as it is scheduled to become a discontinued product. Microsoft's original plan for embedded operating systems was to have them complement the main Windows NT product. However, they (Windows NT Embedded and Windows CE) ended up evolving in different directions, leaving Microsoft with three different operating systems (actually four, if you count Windows 98/ME), rather than one. People who ported products from Windows NT to Windows CE have told me the projects turned out to be much more difficult then they had anticipated since these are really two different operating systems which happen to share some of their API.

Microsoft plans to start over again with Windows XP Embedded, which is intended to work from the same code base as the main line Windows XP. The general intent is to keep all their current operating systems in sync with each other and using a common API. This make sense when you realise that Microsoft's embedded operating systems are intended to support the company's overall strategic goals (e.g., dot-NET), rather than as self-supporting businesses in themselves. It remains to be seen how well this plan (their second attempt) will really work in practice.

It is a little unclear how this will affect Windows CE, as the statements I read about Windows XP Embedded would seem to have this new product covering many of the same product niches as Windows CE - rendering CE redundant. I suppose though that this decision is a few months off yet (or possibly longer). However, Microsoft seems determined to use the introduction of XP to start with a clean slate so I wouldn't be too surprised to see CE either discontinued, or else left to die on the vine.

The above may or may not have any great importance in your decision, but you will likely want to investigate the long term implications it may have for your particular product. There is lots of information available if you read up on the recent Windows XP introduction.

Finally, I thought I should bring up a point which nobody has mentioned, namely cost. If your product is successful, then your bean counters are going to want to know what you can do to make it cheaper. There are two sides to this. The first is development cost, and the second is recurring costs.
Development costs will depend upon a lot of factors, including the quality of the development tools. However, you are developing an embedded system, so make sure you investigate which tools are actually useful to an embedded system developer.
Another point is that you should be using programmers which do have embedded system experience. This is a distinct field from office type applications. I have been told that the typical programmer whose experience is from the office/business field tends to be more of a hinderance than a help in these sorts of projects. In other words, don't think about how easy it is to find a business programmer in order to fill a seat on your development team. You need to do more than just fill seats, you need someone who can contribute relevant experience. I am bringing this point up in case it was a consideration in your operating system choice.

One thing you should be doing is getting the opinions of the programmers early in the project, on things like what a suitable operating system for your product should be. I appologise for bringing this up if you happen to be a programmer yourself, but I have also heard of several projects going wrong because the project managers selected too many operating parameters (OS, development software, hardware, etc.) based on a nice presentation they saw rather than on the actual design details. However, guess who is expected to make it work? (This problem isn't unique to software projects either).

If your product is successful, you will have to deal with recurring costs, which can include software licensing. I'm sure you know about this, but I thought I should bring up a point with often gets forgotten, which is the scalability of the license. By this I mean how economic it is at various production volumes. If initial sales are slow, your company can find itself in a tight spot if lower unit licensing fees only come into effect at higher sales volumes. Your bean counters may not be willing to tolerate losses for several years while waiting for (hoping for) higher sales. This is the death of many products, and not just in the electronics/software field.
What this means is that you have to look at not just what is the licensing cost at the projected (or rather, hoped for) sales volume, but what are the costs you will face on the way there.

I don't really have a particular OS recommendation for you, but I hope the above will help in thinking about the options.

**********************
Michael Griffin
London, Ont. Canada
**********************

 
I am working on an embedded PC control system. After evaluate a lot of vendors, We select IsaGRAF software from Altersys. It allow you to install into any O/S platfoem, and its standard programming language make it easy for all different skill level programmer. You can check their web site at "http://www.altersys.com":http://www.altersys.com , Hope this help.
 
E
If you have the product designed well the user won't have to know or care what the OS is. That's the nice part about PLCs.

Ed

Speaking for me, not for Starbucks. . .
 
B
Perhaps you should go back and read what I actually said. I only suggested a flavor of windows where it might be appropriate, i.e.- where the end user has to interact with the O/S. End users are already familiar and comfortable with windows. They are typically not familiar with linux.

The facts are, that in this case, using linux would put the manufacturer at a serious competitive disadvantage, even if it was a good (or best) choice from other perspectives.

market acceptance is very crucial to getting people to buy your stuff. trying to stuff something down a customer's throat that they do not want, and are not comfortable with, is not likely to win someone a whole lot of business. and thats what it is all about.

i personally do not care what O/S is used. if linux becomes a serious environment for what I am doing, I will do what it takes to learn it. in the meantime, i will learn to deal with what customers want, cause they pay the bills.

Bob Peterson
 
Good luck. It is amazing to me, but no OS meets all of these requirements (IMHO).

Maybe a POSIX compatible system with an ANSI C API. Maybe NT embedded with a real time extension. Maybe Linux with real time extensions. How about Windows CE?

A classic embedded OS for X86, such as PharLap or RTKernel, can use Visual
C++ for development. But I think each developer would need an expensive
development toolkit for the kernel. You need to link the kernel libraries with the program. I think that RTKernel/32 is source compatible with 32 bit windows.

Do you need soft or hard real time. Embedded NT and Linux can both do
soft realtime, if you have a qualified environment. CE is supposed to be hard realtime. QNX is hard realtime, but it fails your first criteria.

When you find one, please let me know.

Bill Sturm
 
B
I think it extremely funny that you would claim Linux has better available support then Windows. I realize you are somewhat of a zealot on this issue, but the few thousand capable Linux people don't even come close to matching the availablity of technical support for various flavors of windows. Not even close.

And available tech support is really only an issue if the end user has to interact with the O/S in some way. If the end user never sees the O/S, the tech support issue goes away at the end user level because the manufacturer can readily train a few (or a few dozen) people to do this work for the end user, which is an entriely appropriate thing to do in many cases.

Since the person who asked the question has given us no information to deal with, its kind of a moot point. perhaps he would care to give us more info.

Bob Peterson

 
Jiri:
> > Market acceptance - Windows. Available support - Linux. Technical
> > capabilities - QNX.

Bob Peterson:
> I think it extremely funny that you would claim Linux has better
> available support then Windows.

Linux support got the InfoWorld award for Best Technical Support in 1997.

"http://www.infoworld.com/cgi-bin/displayTC.pl?/97poy.supp.htm":http://www.infoworld.com/cgi-bin/displayTC.pl?/97poy.supp.htm

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

 
Exist a tool that can be used as operanting system and, at the same time, as a standalone development eviroment but you may consider that it has some disadvantages.

It is considered a obscure language, it have very very different methodology and there exist a few programmers for it.

However it have many advantage for your application if you need a small kernel suitable for real-time embbedded systems. It is easy to understand, to learn, to programm, to debug and to maintain.

I am using it in the developing of a disturbance data colector from a power systems digital relay network. Also I am plaining to use it to control
substation yard instruments which need TCP/IP connectivity. I knew that this tool had been used for instruments control in space application.

I take a lot of words (I want to apologize for that) to tell you that the FORTH language maybe a option.

If you consider a FORTH as valid option you can get more information in

"www.forth.org":http://www.forth.org
"www.openfirmware.com":http://www.openfirmware.com
"www.ultratechnology.com":www.ultratechnology.com

between many others websites

Luis Rios
[email protected]
 
A

Armin Steinhoff

Hi Daniel,

If you mean an operating system which is suitable for an embedded system, then we should at first discuss what 'embedded system' means.

From my point of view an embedded system is a system which is part of a local operation environment and it can only operate within this specific environment. That means the operation of an embedded system isn't location independent .. like a SoftPLC.

A system for general purpose operation, like a PDA, can work at any location. That means a PDA is a small system (in a physical sense) and not an embedded system.

An embedded computing system must work at least as reliable as the rest of its operation environment ... so it has probably to work in 24/7 modus.

It's a good choice to use for 'normal sized' embedded control/computing systems LINUX, SOLARIS, QNX or other UNIXes ... and for small systems with resource constrains QNX.

It's hard to say what is the best OS for 'embedded systems' ....

Best Regards
Armin Steinhoff

www.steinhoff-automation.com

 
Top