> The problem is not Windows. It's a lack of knowledge and understanding. Simple. Yes, if there was a minimum of knowledge Windows wouldn't have been used.
Disclaimer: I work for Microsoft.
71–80 of 211 posts
> The problem is not Windows. It's a lack of knowledge and understanding. Simple. Yes, if there was a minimum of knowledge Windows wouldn't have been used.
Disclaimer: I work for Microsoft.
This situation is even funnier(and sadly very seriously flawed) in Japan. Medical equipment require an authorization to use. Any change to the medical equipment requires another authorization or it's prohibited. By "any change" , it includes Windows Update(it changes the system obviously). The result: they use anti-malware software to protect(or rather, believed to protect) unpatched Windows. At least one anti-malwar…
Honestly, this isn't a bad decision. If the device was tested and certified with specific software, a software upgrade is not guaranteed to not cause a problem.
Earlier quoted context omitted.
I would expect these kinds of systems to be running a soft realtime OS. Or at the very least a run of the mill OS with no extraneous software running in the background.
This. How are these devices not running on some sort of hardened OS seen in airplanes and automotive? Medical applications are mission critical (or some variant) and should have same (or better!) certification procedures set up for correctness and security.
Aeronautical and Automotive are both engineering driven, Medical isn't, it's a big grey area.
Earlier quoted context omitted.
I think you have it backwards (no disrespect intended). When you evaluate the choice of Windows you have to acknowledge that it brings with it the vulnerability of viruses and so the necessity of anti-virus software. Either you own that decision, and as part of your support your tool provides the necessary antivirus and you also insure through testing configuration management that its configured appropriately, or you…
> When you evaluate the choice of Windows you have to acknowledge that it brings with it the vulnerability of viruses and so the necessity of anti-virus software. No matter what OS you choose it is vulnerable to viruses. You and I will agree that the odds are your Windows system is much more at risk by at least an order of magnitude. But the IA people who demanded that this system run antivirus are just as likely to…
This may be theoretically true, but it is not practically the case. There is a reason Linux and OS X users almost never use antivirus software.
Using Windows on a medical device is inexcusable. It's a heart monitor, not a game system.
> The problem is not Windows. It's a lack of knowledge and understanding. Simple. Yes, if there was a minimum of knowledge Windows wouldn't have been used.
Get out of here with that nonsense. You may not be a fan of paid software, but the Windows Kernel is just as good as any FOSS kernel today in regards to stability. The Server and embedded SKUs also come with a ton of the extraneous stuff removed that one would ever be worried about. The issue here is that someone decided that a machine that should only ever be connected to an air gapped network needed anti-virus soft…
I disagree strongly, but this is beside the point. Medical hardware should not be using any operating system that's not hard real-time and thoroughly vetted. Ideally they would use no OS at all. Even Linux, which is drastically more appropriate for embedded systems, is a questionable choice for medical equipment.
/rant/ I can't tell you how many times we've chased down field problems that ultimately were the result of antivirus scans. It's been so bad, that one of the first questions we now ask when we get a tool-down report is "is there antivirus running and what is the configuration?" Bringing Windows into the architecture of any type of capital equipment control system is a bane. A scourge. I mean to say, it really is a mi…
The company claims that they included proper instructions in their documentation, advising companies to whitelist Merge Hemo's folders in order to prevent crashes from happening, so it seems that the whole incident was nothing more than an oversight on the medical unit's side."
Here's how I read that: The programmers of this piece of software assumed that some I/O operation would never fail and when it does the program shits itself. So instead of hardening their software to withstand loss of telemetry gracefully, which would cost time and money for the company, they just give instructions to disable scans on their folder.
Odds are good that somewhere this scan will happen (and it did). Either IT doesn't read the release notes or goofs the configuration or an antivirus update clears the white list. Might not even be the antivirus that interferes with the telemetry briefly.
But instead of having resilient software it's "the anitvirus software's fault" or "it's IT's fault" when something goes wrong because of their bad management/engineering decision.
This situation is even funnier(and sadly very seriously flawed) in Japan. Medical equipment require an authorization to use. Any change to the medical equipment requires another authorization or it's prohibited. By "any change" , it includes Windows Update(it changes the system obviously). The result: they use anti-malware software to protect(or rather, believed to protect) unpatched Windows. At least one anti-malwar…
But... what about AV/malware definition updates? Doesn't that fall under "any change"?
> The problem is not Windows. It's a lack of knowledge and understanding. Simple. Yes, if there was a minimum of knowledge Windows wouldn't have been used.
Get out of here with that nonsense. You may not be a fan of paid software, but the Windows Kernel is just as good as any FOSS kernel today in regards to stability. The Server and embedded SKUs also come with a ton of the extraneous stuff removed that one would ever be worried about. The issue here is that someone decided that a machine that should only ever be connected to an air gapped network needed anti-virus soft…
No it's really not. I've used Windows and Linux a lot and in 10 years of using Linux I've only twice had a kernel panic while using non-experimental software.
On Windows I've had countless BSODs.
Earlier quoted context omitted.
I worked on similar software that ran on Windows, though the decision was made 18 years ago. It was driven by: * GUI dev tools were an order of magnitude better than under linux * nidaq (very common daq and dio cards) didn't have or had flaky linux drivers. usb may be a better choice today but was not then available. Plus it's convenient/less expensive to push functionality to the computer side and minimize embedded…
every software update to the machine has to be FDA certified Interesting. Does that imply that every Windows update Microsoft releases has been FDA-certified already?
Now based on the class of medical device you are developing, you can either get to use SOUP without justifying at all, or you have to explain/justify why you can use SOUP at all.
For example, even if your OS was Linux, because you don't have formal documentation on verifying that Linux infact does all the things its suppose to do (hell, does Linux even have a true spec?), you would then have to justify why you're using Linux. If a kernel update comes out, you then have to justify why you're using it.
What you WOULD have to do is verify/validate that your software that interacts with SOUP (so in this case running on an OS) still works correctly. You would not have to verify/validate the OS update per se.