Selecting the right operating system can have a hugely positive or negative impact upon the success of your project and can be a minefield. Ascertaining sufficient knowledge of what options are available to be able to make that decision can be a steep learning curve, particularly if that conclusion is one that must be made by the relatively uninitiated.

Microsoft would have you believe they have the perfect operating system for every embedded application. Others would vehemently disagree that not one of Microsoft's offerings is even close to what they'd deem "embedded" – though of course that latter term is open to wide interpretation.

Some would consider "embedded" transparently to dictate any platform that's embedded inside a larger machine. I couldn't believe my eyes recently when, for the first time, I saw the inside of a mobile ATM and there sat an old, creaky desktop PC, responsible for handling hundreds of thousands in cash; is this technically embedded?

Those who historically consider themselves embedded developers would postulate true "embedded" lies at the other end of the scale, where a strictly single-purpose system is adhered to in all aspects of the design, not purely by the front-end software.

In fairness to the ATM's bizarre desktop hardware, thankfully it was employing XP Embedded, rather than the enterprise version! Though many struggle to make the correct decision.

The functionality "tick box" exercise is of course where to start; naturally if an OS doesn't support your functional requirements then it's out of the frame immediately, but the refinement should continue much further beyond this.

The consequences of failure is a key consideration to consider when selecting an OS – what could cause such a failure and what steps does the OS take to protect against it? For example, few embedded applications would involve someone cleanly shutting down, which rules out most Microsoft enterprise options, or at least should!

Beyond simplification – less that can go wrong – more embedded applications often employ read-only partitions for the OS storage, or run entirely from RAM; thus even in the very worst case scenario the system can be reset to default simply through a reboot. Though perhaps the application is so mission critical that even that possibility just isn't acceptable – this is where the specifically "high reliability" platforms really come into their own.

Real-time operating systems (RTOSs) such as QNX and ThreadX have been utilized in mission critical applications for decades – rail, automotive, and medical applications to name but a few. Whilst their value cannot be denied, I've seen outlandish suggestions of its utilization within the polar opposite of mission critical scenarios; a recent example was a theatre Panel PC designed to show people to their seats and literally a single unit was required. Of course the term "high reliability" is perceived as important to all, but it's equally important to remember it's always relative.

This brings me nicely onto my next point: quantity. Such RTOSs often involve significant upfront costs, rarely a concern on the projects they are designed for as they typically run into tens or hundreds of thousands of units. You could argue Linux also falls into this category, not because of up front software cost, but involved software development effort – which is cost in itself.

Actually, it's easy to argue when looking at the total cost of ownership over the production quantity, that sometimes the enterprise option actually is the most suitable. Yes it can be difficult to accept a license fee of nearly $200 within a unit cost, but pit this against the $1,000 cost of an embedded MS toolkit, or hours of development on a license-free OS for a small quantity of units. The financial implications are obvious.

This simplistic equation of development cost + license cost per unit x production quantities is incredibly important, though strangely isn't always considered. It naturally correlates that those with the largest upfront costs/effort are suited to higher quantity projects, where that cost is easily amortized across the production units.

This is never black and white, though. Companies offering pre-installed embedded OSs (thus removing the development tool cost) and those with in-house license-free OS expertise may not consider such development a real cost.

Just don't take that decision lightly...