Embedded software applications are like the mammals of the software industry – while the monolithic dinosaur applications slug it out up in broad daylight, the embedded apps scurry about in the undergrowth doing what they do best, hidden from all but the most observant.
While this isn’t an analogy you’d want to push too far, it’s certainly the case that embedded software can be found in the strangest places. Some of the more esoteric examples you gave us in a recent poll were buoys and Bluetooth energy meters, CAT scanners, endoscopes and pulse oximeters, hyperbaric welding systems, web based laundry control systems and our personal favourite – car catapults for crash testing.
But what OS is in the box? Unsurprising perhaps is the dominance of Linux in this space. I should perhaps say unsurprising to me, as it does appear to have achieved a level of “de facto” status among many of my old programming colleagues. But indeed, from our poll it does appear to have a fair share of the market. Second in line are commercial operating systems such as VxWorks, Microware OS9 and QNX, followed by other open source operating systems and (finally) Windows Embedded.
Now, without dwelling for too long on Microsoft’s misfortune (apart from to say QED to “Microsoft is not going to take over the world” yet again), it’s worth looking at why respondents actually choose specific embedded operating systems. We know from a previous article from my colleague Tony Lock, that from a developer perspective, tools availability came top of the list – clearly that’s going to make a difference. But when it comes to features and functions, the stability of the OS is way ahead of the rest.
As one of the comments to Tony’s article illustrate, this can be no mean feat.
Real programmers have to make it work! The challenge of making anything go at all is the greatest one in embedded development – hence the focus on tools and emulators. Buggy compilers, crash-prone in-circuit emulators, invasive tethered debugging solutions are all part of the battle-scars of the experienced embedded software engineer.
Which brings us to the point – that embedded systems really don’t take prisoners. If your hyperbaric welding system, endoscope or indeed car catapult stops working, you’re not necessarily going to be in a good position to call technical support. Particularly, it has to be said, with the endoscope.
This does also give us additional insight into the “Microsoft” question. From both the first chart and from direct poll feedback, the negative view on Windows Embedded/CE does appear to be based on historical experience and general hearsay. That is, even if things are better now than they were (I don’t know, just speculating), the company might have a challenge on its hands to convince people this is the case.
When it comes to operations and management criteria, number one in the list was cost of licensing, but only just – with application maintainability/manageability also featuring highly, again supporting the principle that ‘it’s just gotta work’. Right at the bottom was the need for major vendor support – while this might appear reasonable, this is a different picture to what we might expect to see for non-embedded applications.
As a final point, to our chagrin we were quite rightly pulled up by the group who told us we had missed the option of not needing an OS at all. To be fair, this group would find it significantly easier to decide between the options, rendering much of the poll moot. For the rest, and indeed for anyone working in a sphere where everything has to just work, IT choices in general become a lot more stark. Developers and managers of other application types could probably learn a great deal from how these well-concealed systems are built and deployed.