Developer discussions about operating systems frequently reach a fevered pitch. Finding a calm discussion on this topic is always a treat. A Windows developer - and a developer on one of the currently available "smart" pump products - offers the following:
today. The issues that this particular article raises have been felt
throughout the medical industry. I found it rather ironic less than a
month ago when a Microsoft employee asked me why the medical industry
don't seem to be latching onto Microsoft products.
The writer goes on to suggest that Windows is awfully buggy for use in safety critical applications, and that Microsoft's vendor support is better suited for general purpose applications developers than embedded medical device companies. All software is buggy, and that is why embedded systems are subjected to rigorous verification and validation (V&V) where those bugs - in the application and the OS - are rooted out and resolved. Embedded developers do require a different level of support that goes beyond what Microsoft can deliver, that's why Microsoft has partnered with (and subcontracted to) companies like BSQUARE.
connectivity between all devices around a bedside with each other and
to central systems there are inherent risks. Unfortunately the
Microsoft OS seems to be causing additional levels of complexity and
cost when implementing such systems. When these very expensive systems
have been developed and flaws in the underlying OS are found they are
fixed in the PC devices but how often do you think they are fixed in
the older embedded devices? These can be headless devices that don't
even look like a pc. I mean honestly. The cost of fixing Microsoft
faults costs big medical companies millions and one of these days
Microsoft will probably find themselves in legal issues regarding this.
Especially if they advocate that these embedded systems are inherently
safe and reliable.
There are three advantages to using Microsoft: the "ubiquitous connectivity" that's bundled in the OS, developer productivity when working in a homogenous Microsoft environment, and a ready supply of developers familiar with Microsoft technologies. These days, there are competitors with plenty of connectivity in their embedded operating systems products. Another Microsoft advantage is cost - unlike some of their competitors who get their money up front charging for tools and development environments, Microsoft get's most of their revenues on the back end in license fees attached to shipped products (which can be pretty stiff, and the main reason there are no "high availability" telemetry central stations from vendors running on Microsoft).
I don't really see Windows "causing additional levels of complexity and
cost," unless she's referring to the additional effort required to step out of a pure Microsoft environment and into the real (and heterogeneous) world. The fact that many medical devices running Windows don't look anything like computers has, I think, resulted in some medical device security issues due to a lack of awareness and understanding.
The biggest problem I have with Windows is its role as hacker's favorite target (by far) for malicious code. The hacker bulls eye on Windows' back is not going away any time soon. Both Microsoft and medical device vendors are getting better at medical device security, but to date only one vendor has announced any formal effort to build medical device security into their products (you can read about that here).
Another weakness of Windows is the need to effectively rewrite your product when Microsoft comes out with their "next" development environment - that is if you want to continue to receive support from Microsoft. This doesn't happen often, but when it does you must respond, putting a supplier (Microsoft) in the role of dictating product roadmaps and R&D investments. If you're using something like Linux, you can stay migrate to new versions when at the time of your choice.