3 ms·

Why on earth is medical equipment running standard Windows? This is the ideal location for some basic RTOS or even just an embedded Linux. Seems like a huge cos

Why on earth is medical equipment running standard Windows? This is the ideal location for some basic RTOS or even just an embedded Linux. Seems like a huge cost and risk for no gain.

riyadparvez 10y ago
That was my first thought too. And why there is an anti-virus running? This equipment should not be connected to the internet nor some staff should plug-in a flash drive on the first place.
- ars 10y ago
  That's not true. They have to keep a record of the data for the patient file. So it does have to communicate remotely in some fashion.
  - GunboatDiplomat 10y ago
    Could communicate with a gateway bridging a private medical devices network and a public network. That seems a reasonable way to provide control and access.
tluyben2 10y ago
It's cheap to find Windows programmers and even cheaper to find ones that are not hindered by knowledge about software quality and safety. That's not their fault; no-one ever told them something like that exists.
- nonbel 10y ago
  >"hindered by knowledge" This is a great phrase. "Joe was hindered by knowledge of what a p-value means and so didn't claim he discovered a key to understanding the disease."
kosmic_k 10y ago
I never realized just how lucky I was to have been born when I was. I can't imagine building embed devices which aren't running a very simply super loop or an ARM RTOS.
devonkim 10y ago
I believe that it's strongly related to the dashboard software being targeted towards "familiarity" by the doctors / customers and having old GUI-centric software from back in the mid-90s ported to run on Windows over the decades prettied up back when there was nothing really viable for end-user accessible embedded systems besides even more grotesquely expensive custom software with even less capabilities and far worse SDKs than anything under Windows back in, say, 1994. This isn't that different to me than banking software with a COBOL backend with Java middleware and a PHP frontend that's extremely common for retail banking sector. Given the sheer amount of overhead in enterprise BS medical hardware has (read: sales people likely get the biggest chunk of the absorbed costs) it wouldn't be a surprise to me that the engineering teams amount to a skeleton crew while 70%+ of the personnel involved are non-engineers that override the professional decisions of the engineers.
technion 10y ago
I feel there are two very contradictory views on HN. The first of these, is that anything safety critical needs to land on an RTOS. The second of these, is to avoid C. Both of these have reasons behind them and appear to make sense. Leaders in the RTOS space appear to be QNX and vxworks. Suitable languages people raise are Rust and Go. Based on some Google time, neither of these platforms support either of these OS's. Multiple "Introduction to vxworks" documents are all exclusively in C. In terms of accessibility, safe languages are far easier for someone to get their hands on, test to death, than some of the OS's recommended.

Why on earth is medical equipment running standard Windows? This is the ideal location for some basic RTOS or even just an embedded Linux. Seems like a huge cost and risk for no gain.

riyadparvez 10y ago

That was my first thought too. And why there is an anti-virus running? This equipment should not be connected to the internet nor some staff should plug-in a flash drive on the first place.

ars 10y ago
That's not true. They have to keep a record of the data for the patient file. So it does have to communicate remotely in some fashion.
- GunboatDiplomat 10y ago
  Could communicate with a gateway bridging a private medical devices network and a public network. That seems a reasonable way to provide control and access.

tluyben2 10y ago

It's cheap to find Windows programmers and even cheaper to find ones that are not hindered by knowledge about software quality and safety. That's not their fault; no-one ever told them something like that exists.

nonbel 10y ago
>"hindered by knowledge" This is a great phrase. "Joe was hindered by knowledge of what a p-value means and so didn't claim he discovered a key to understanding the disease."

kosmic_k 10y ago

I never realized just how lucky I was to have been born when I was. I can't imagine building embed devices which aren't running a very simply super loop or an ARM RTOS.

devonkim 10y ago

I believe that it's strongly related to the dashboard software being targeted towards "familiarity" by the doctors / customers and having old GUI-centric software from back in the mid-90s ported to run on Windows over the decades prettied up back when there was nothing really viable for end-user accessible embedded systems besides even more grotesquely expensive custom software with even less capabilities and far worse SDKs than anything under Windows back in, say, 1994. This isn't that different to me than banking software with a COBOL backend with Java middleware and a PHP frontend that's extremely common for retail banking sector. Given the sheer amount of overhead in enterprise BS medical hardware has (read: sales people likely get the biggest chunk of the absorbed costs) it wouldn't be a surprise to me that the engineering teams amount to a skeleton crew while 70%+ of the personnel involved are non-engineers that override the professional decisions of the engineers.

technion 10y ago

I feel there are two very contradictory views on HN. The first of these, is that anything safety critical needs to land on an RTOS. The second of these, is to avoid C. Both of these have reasons behind them and appear to make sense. Leaders in the RTOS space appear to be QNX and vxworks. Suitable languages people raise are Rust and Go. Based on some Google time, neither of these platforms support either of these OS's. Multiple "Introduction to vxworks" documents are all exclusively in C. In terms of accessibility, safe languages are far easier for someone to get their hands on, test to death, than some of the OS's recommended.