On Sun, 27 Jul 2008 21:31:02 -0500, Jack Klein <j...@spamcop.net>
wrote:


>Right now, the product (a medical imaging device) must ship with at
>least two x86 computers.  One, the image acquisition computer, runs
>QNX 6.something.  The other, which is the user workstation and
>interface to the hospital/clinic network, DICOM translator, image
>processor, archive, etc., runs under Windows XP.

Is this ordinary Win XP or Win XP Embedded ? If XP, I would be quite
concerned with the remaining life cycle for XP, the Win XXX Embedded
versions have had at least in the past a longer life cycle (e.g. no
W2k Embedded, so NT4 Embedded lived for quite a long time). 

>Having two computers instead of one is an expense in and of itself.
>Beyond this, it is a maintenance headache.  Any particular x86 box
>these days is not available for a great length of time.  

I do not know about the processing power requirement for your QNX
system, but usually the x86 embedded boards have a much longer life
cycle then ordinary desk top boxes. However, the RoHS requirements may
prematurely terminate the production of some older non-RoHS boards due
to lack of non-RoHS components.

For the user interface box, you are still going to have to replace the
box due to the increasing resource requirements of future Windows
operating systems.

>By the time
>we are shipping a particular new computer, its end of life is already
>announced and we are qualifying and validating the next one.
>
>Seeing as how this is a medical device, which is a highly regulated
>industry by the FDA in the US and corresponding agencies in other
>countries and regions of the world, the overhead of testing and
>documenting any change in hardware is quite substantial.

At least for the QNX box, you should be able to extend the life cycle
and thus reduce the requalification costs, with suitable choice of
hardware, especially if you do not need the absolute top performance
for the application.

>Right now we are continuously validating not one, but two different
>replacement computers at any give time, for two different sets of
>operating systems and applications.
>
>If we can successfully run QNX and the application on a VM under XP,
>there is now only one computer to validate for hardware updates.

When there are some severe realtime requirements for a system running
a general purpose OS (Such as Windows or Linux), the usual practice is
to use a real time extension, which in practice is a RT-kernel running
the RT application and then running the general purpose
(Windows/Linux) OS as the null/idle task in the RT-kernel, using the
unused CPU would have otherwise been used by the idle loop.  

>The other great savings potential is simply the fact that new x86
>hardware (motherboards, BIOS, network cards, etc.) always ship with
>Windows driver support.  It is not always so easy or quick to have or
>get QNX drivers for the latest, newest hardware.

Do you absolutely need the newest hardware for performance issues or
due to end of production for the older card ?

Paul

On Sun, 27 Jul 2008 23:12:35 -0500, AZ Nomad
<a...@PremoveOBthisOX.COM> wrote:

>On Mon, 28 Jul 2008 06:46:50 +0300, Paul Keinanen <k...@sci.fi> wrote:
>>On Sun, 27 Jul 2008 22:00:42 -0500, AZ Nomad
>><a...@PremoveOBthisOX.COM> wrote:
>
>>>
>>>Baring that, why not just have two PC's sitting side by side?  How
>>>tightly coupled are the operating systems in the final application?
>>>How do they interface?
>
>>There are (or at least have been) rack mountable boxes available with
>>two separate passive backplanes with separate power supplies. Add just
>>a KVM switch and the system looks just like a "single computer" as the
>>customer wanted. Of course you can run different operating systems or
>>even different processors on the two backplanes.
>
>I bet they cost a heck of a lot more than two PC's.

Sure it is, but my guess is that the computer box cost is
insignificant compared to the total life cycle costs of the OP's
system.

My experience with passive backplanes is from the days of ordinary PCI
backplanes, the PCI Express may have complicated things.

Paul

On Sun, 27 Jul 2008 21:31:02 -0500, Jack Klein <j...@spamcop.net>
wrote:

>Right now, the product (a medical imaging device) must ship with at
>least two x86 computers.  One, the image acquisition computer, runs
>QNX 6.something.  The other, which is the user workstation and
>interface to the hospital/clinic network, DICOM translator, image
>processor, archive, etc., runs under Windows XP.

That requirement sounds that you should use more than two computers
(or at least several XP systems in VMware etc.). Keep the QNX system
on a separate hardware and the VM system on a different hardware. 

It would be natural to keep the general XP specific part on one VM and
the country and hospital specific part on the other XP VM. It is quite
likely that the hospital side may be updated at some time different
for the update time of the rest of the imaging system.

By the way, for how long are you required to provide spare parts and
support for your system, one year, three years or ten years or more ?
This will also dictate what kind of hardware to use and how to
partition the functionality into different (real or virtual) boxes. 

Paul
 

In article <p...@4ax.com>,
 Jack Klein <j...@spamcop.net> wrote:

> On Sun, 27 Jul 2008 12:12:45 +0100, Colin Paul Gloster
> <C...@ACM.org> wrote in comp.realtime:
> 
> > On Wed, 23 Jul 2008, Dombo wrote:
> > 
> > |---------------------------------------------------------------------------
> > |-----|
> > |"> On Tue, 22 Jul 2008 22:07:49 -0500, Jack Klein <j...@spamcop.net> 
> > |wrote:|
> > |> > I'm looking for any suggestions, and especially any real experiences,  
> > |> >      |
> > |> > that anyone cares to offer.                                            
> > |> >      |
> > |>                                                                          
> > |>                                 |
> > |> > We have a system that includes an x86 box running QNX 6.something.  It 
> > |> >      |
> > |[..]                                                                       
> > |     |
> > |                                                                           
> > |                                  |
> > |I'm not sure how well the QEMU solution would meet the 'real time 
> > |performance'  |
> > |the OP mentioned. Also QEMU is quite slow since it emulates the processor 
> > |as    |
> > |well.                                                                      
> > |     |
> > |                                                                           
> > |                                  |
> > |Though there are plenty of VM's (Virtual PC, VirtualBox, VMWare), I think 
> > |it is |
> > |unlikely one will find a VM that allows guests OS'es to provide hard real 
> > |time  |
> > |guarantees while running in that VM.                                       
> > |     |
> > |                                                                           
> > |                                  |
> > |Unfortunately the OP wasn't specific about the real time deadlines that 
> > |had to  |
> > |be met, or the host OS."                                                   
> > |     |
> > |---------------------------------------------------------------------------
> > |-----|
> > 
> > I have not used QNX in QEMU, but I have noticed that the throughput of
> > a simulated operating system in QEMU can be impressively high
> > (depending on what is being done) if the host operating system does
> > not need to use virtual memory for the simulation (i.e. if the
> > simulation can be kept within the host computer's main memory). The
> > high throughput is still accompanied by QEMU's high latency however. I
> > was not trying to access any external hardware, which may make this to
> > be a less useful example for Jack.
> > 
> > I do not know why the people Jack mentioned no longer want a perfectly
> > functioning QNX native installation. I used to study with someone
> > whose master's thesis was about a Windows system he developed by
> > porting a QNX application which he did not develop to Windows. Why do
> > people do these things?
> 
> Since you asked, I will be happy to reply.
> 
> Right now, the product (a medical imaging device) must ship with at
> least two x86 computers.  One, the image acquisition computer, runs
> QNX 6.something.  The other, which is the user workstation and
> interface to the hospital/clinic network, DICOM translator, image
> processor, archive, etc., runs under Windows XP.
> 
> Having two computers instead of one is an expense in and of itself.
> Beyond this, it is a maintenance headache.  Any particular x86 box
> these days is not available for a great length of time.  By the time
> we are shipping a particular new computer, its end of life is already
> announced and we are qualifying and validating the next one.
> 
> Seeing as how this is a medical device, which is a highly regulated
> industry by the FDA in the US and corresponding agencies in other
> countries and regions of the world, the overhead of testing and
> documenting any change in hardware is quite substantial.
> 
> Right now we are continuously validating not one, but two different
> replacement computers at any give time, for two different sets of
> operating systems and applications.
> 
> If we can successfully run QNX and the application on a VM under XP,
> there is now only one computer to validate for hardware updates.
> 
> The other great savings potential is simply the fact that new x86
> hardware (motherboards, BIOS, network cards, etc.) always ship with
> Windows driver support.  It is not always so easy or quick to have or
> get QNX drivers for the latest, newest hardware.
> 
> At least some VM implementations virtualize hardware interfaces such
> as NIC, serials ports, USB controllers, so they look generic to the
> guest OS.  That can also save some headaches.

I have to ask:  Why even have Windows-anything in the picture?  There 
are lots of one-box Linux cum realtime approaches available, and a 
two-box solution (QNX in one, vanilla Linux in the other, enet between) 
would be dead simple, and either approach would be far more stable than 
Windows, both immediately, and also in avoidance of the Windows Upgrade 
Treadmill.  

If (as others have suggested) you use industrial-grade hardware, the 
treadmill will churn far slower than with consumer PCs as well.

Joe Gwinn