On 3/26/21 1:39 PM, Michael Jackson wrote:
I'll start off by acknowledging your points, but we will just agree to
disagree. I acknowledge that you have a*lot* of years making/maintaining
software for medical devices. But I'm with Hamish on this. I don't understand.
What you are saying is that Qt was designed "perfectly" from day one with no
extra API, not one bad API implementation and no cruft. Qt should never be updated to run
on modern compilers against modern C++ specifications. Updated to run on modern operating
systems. Qt should not explore adding APIs/Toolkits to the Qt ecosystem to allow Qt to be
used on the billions of devices that we use every day. Qt should just stick with its
technology from 20 years ago. TQtC shouldn't go after paying customers in order to, you
know, pay its developers. TQtC should rely solely on an industry that, by your own
writings, have a 15 year horizon. Not much of a business case for that. (For the record,
I don't particularly agree with TQtC current licensing or LTS strategy.)
No. Not what I'm saying at all. I have no idea how you got there from
what I've said.
Stable API. Nothing ever gets deleted until it has a direct or mostly
replacement *within* the existing product.
When Qt chased these markets it knew what the lifetimes would be. Now it
has abandoned them.
I also don't understand your argument that you want to update a medical device
from 20 years ago with the latest and greatest toolkits. I can't imagine
anything electronic from 20 years ago being able to actually load and run
anything like Qt? How is the hardware even powerful enough to do this? You
can't convince me that the medical hardware device manufacturers were thinking
15 years into the future for the next upgrade, 15 years ago.
The surgical robots being sold today will require 20 year support
lifespans. Many of the devices sold over the past decade were sold with
a minimum 10 year support and maintenance requirement. The development
effort on these devices runs into the millions. You can't make a bet
like that and find out a year later the supplier flew off to the Cayman
Islands with Ted Cruz and your money.
50 Year Old equipment. You make the case even more for TQtC to pursue customers
with a much shorter timeline. If TQtC concentrated on markets with 20-50 year
timelines for updates how much revenue do you think they would make? Enough to
sustain Qt development in any real capacity? Doubtful.
Okay. There's an education situation here.
I've never worked for a one-trick-pony medical device company. For
certain there are the grant/research funded things coming out of college
labs. That Phd. student doesn't take it to production. A Baxter,
Hill-Rom, GE, etc. type player will be who said thing gets sold to. They
will take it through FDA approval and to full production. Usually they
end up hiring the person or small college team that created it.
Baxter (and I imagine all the rest) actually invest in many tiny startup
medical device companies if there is a good idea that has already had
some fundamental work. They invest with the intent of consuming some/all
of it when it is obvious the thing will work. Here, this might help.
https://www.gehealthcare.com/products/accessories-and-supplies/clinical-accessories-and-supplies
Click on Products & Services and then click Equipment and follow across.
Those are just the devices GE puts out under its *own* brand. It owns
whole or in part lots of other little companies putting out medical
devices under their own brand. Hill-Rom is much the same from that
perspective.
You are thinking in terms of the x86 world where there are oceans of
one-trick-ponies. Companies like Install-Shield that had one big hit
followed by some flame-outs. Last I heard they were still just a one
product company. It's a cultural thing tied to that platform.
Here's reality in the medical device world.
Year one you get told to create a new patient monitor that looks like
any of the ones in this list of images.
https://duckduckgo.com/?t=canonical&q=patient+monitor+image&iax=images&ia=images
It has a pump for blood pressure cuff, SP/O2, thermometer, and ability
to record/display some patient info like weight and body mass. The UX
team comes up with a style, fantastic graphics, even a custom font to
support all of the supported languages. Management tells you what they
are going to buy for a processor and RAM. They put a stake in the ground
on battery life and recharge time, etc.
You work like dog for 6-8 months. Product goes off for FDA approval. The
day __after__ everybody goes out for drinks management team tells
hardware team to split into two groups.
Group 1: Design and build a new & improved hospital bed with built in
scale so nursing homes don't have to get immobile people up to weigh
them. (For those who don't know, they are required to record resident
weight at least monthly. One of the dead give-aways for abuse is
significant weight loss without doctor visit.)
Group 2: Design a mattress or mattress cover to be a patient monitor for
burn victims and other people whose skin is in such a condition you
cannot use a blood pressure cuff or the SP/O2 finger clip.
Group 1 won't need much for software people. None if they purchase a
prepacked scale display. Group 2 is going to re-use much of the source
code from the just completed patient monitor for the UI and device
messaging. If they've never built one of these before the real work is
in the mattress or mattress pad. I don't know how they do it, but some
of them manage to get blood pressure.
When you are just about done with that product management pulls the bulk
of the software team off to work on a surgical robot.
These companies purchase a tool set and usually purchase support
contracts for it. They pay lots more for tool sets that have already
done all of the paperwork for the FDA. When it is a tool set suffering
"massive churn" the constant testing and re-certification gets
prohibitively expensive.
BlackBerry makes a lot of money with its certified QNX.
https://blackberry.qnx.com/en/software-solutions/embedded-software/medical
I think there is also someone selling a certified version of FreeRTOS.
If the tool(s) you use don't already have this proof and haven't already
been blessed by the FDA, you have to get it done. Here is a write-up
that I just quickly skimmed and won't be offended if you don't actually
read.
https://www.integrasources.com/blog/linux-os-for-medical-devices/
The only phrase you have to worry about is SOUP. Software Of Unknown
Provenance. Your Yocto build of Linux falls under that. If Qt is
churning, it also falls under that unless QtC is continually going
through FDA approval. CI has to include FDA approval process which is
neither automated nor quick.
In a previous message I gave you the different layers going up from bare
metal to RTOS (hard certifications required, no dynamic memory, etc.)
Then I told you about the COMM module most manufacturers are moving to.
This is a physical thing that can be certified independently then used
on any number of devices. It removes all penetration threat because
there now is no outside world connection for the device. It has a serial
connection that accepts only a fixed group of messages throwing the rest
away. Your Yocto build doesn't have a network stack, just the PPP type
driver.
So, putting this into a shot glass for everyone, when you are working
for a medical device company you are on something of a device treadmill.
Once a device is launched it is expected to have a 15+ year life. You
**will** have to support it for 15+ years, but you won't re-engineer it
until then.
While that device is out there making lots of money and saving lives,
you will use the same tools to work on many other devices.
You can't keep re-introducing SOUP every few months. Someone either has
to get SOUP certified __or__ you have to mitigate RISK by removing all
potential for SOUP to cause patient harm. One of the main mitigations is
the message based design. Another main mitigation is the inclusion of an
"easily accessible during emergency yet physically protected" physical
off switch. You can't have a touch screen power down icon be your only
method of shutting something off.
It is impossible to mitigate all RISK with something like an infusion
pump. You can have the most perfect drug library in the world. It can
have the most perfect of rules for dosages and one stupid bug that
slipped through testing could send down 7L/hr instead of 7ml/hr. The
driver for the pump motor has to have safety built into it that caps
volume at a safe level. 7L/hr is going to blow a vein.
Because of SOUP and certification costs these companies tend to pay big
bucks up front for good tools and they also tend to purchase support
contracts.
The *do not* do subscription licensing. They generally don't do per-seat
licensing.
When they pay for something like a support contract they expect
**actual** support, not bugs rotting in a bug database for 12+ years and
definitely don't take kindly being told "it's too hard to fix" or "if we
fix it then other things will break."
If they pay for support on RHEL 6, you don't get to just drop the
platform because it is inconvenient.
The entire purpose of choosing a high level application framework is so
the kernel doesn't matter. The stable API remains the stable API. Under
the hood remains under the hood.
--
Roland Hughes, President
Logikal Solutions
(630)-205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
