Comments on RTOSes

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hello all.

I am starting a research to identify a RTOS to be deployed in several
medical products. The product line includes some low to medium end
products based on Xscale (PXA255) and some medium to high end products
based on x86 compatible processors (Geode at the moment, some Intel
offspring in a near future).

Some of the main requirements I have to guide my research are:
1- Reputable manufacturer (in both market time and product record.)
2- Support to the architectures above.
3- Decent development tools.
4- Good networking support.
5- Decent graphics support (optimized graphics drivers desirable.)
6- File system with fault recovery (FAT16/32 compatible if possible).
7- Flash file system availability.
8- Scalability (low footprint on small systems).

Some of the products may work stad alone whereas others must be network
connected to exchange information with other medical systems (clynical
software, image archiving systems etc.) and that is the reason for the
4th item above. Different resource requirements are foreseen, going
from moderate (when information exchanged is mostly patient related
data, and system status and configuration data) to high as running some
sort of java virtual machine (at low priority) is a possible
requirement to make software development people's life easier when
developing some clients to be connected to the aforementioned systems.

There are some other requirements but the above are the most important
and are in (sort of) order of importance for all the personnel involved
in product development (for many of them, item 3 should be on the top
of the list.) Also the above above may seem somewhat limited but I am
assuming others more technical such as IPC mechanisms, fault tolerance,
fault recovery capability, memory protection between processes, bounded
latency, priority inversion mitigation and so forth are met in some way
by the candidates on the top of my list.

After a quick preliminary research I am considering the following
RTOSes: QNX, LynxOS, VxWorks, Integrity and OSE.

I believe each product may excel in some requirements but not in
others. Therefore I would appreciate if you folks could provide some
insights on this matter to provide me with some information that help
me to make a decision. Suggestions on others RTOSes that could fit and
are worth taking a look are welcome too.

Thank you very much in advance for your help.

Josias.


Re: Comments on RTOSes

Quoted text here. Click to load it

One company that I have worked alongside in such projects is MPE (see
http://www.mpeltd.demon.co.uk /). This was for an anaesthesia ventillator on
which I assisted in software inspection and certification.

Quoted text here. Click to load it

Not sure if they currently hit all your target processors but they find it
relatively easy to add another processor to the list they do
cross-compilers for.

Quoted text here. Click to load it
Goes without saying in such an application. Yes, they are fairly decent
tools to use.

Quoted text here. Click to load it

These last items should also be no real problem for them.

[%X]

As you have mentioned that this is for medical devices I am certain that
you require companies that have had experience with CE (Medical Devices)
and FDA approvals processes, and have a track record of producing excellent
quality software and documentation.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Comments on RTOSes
Quoted text here. Click to load it

Consider Express Logic & ThreadX/NetX/FileX:

http://www.expresslogic.com

-->Neil

Re: Comments on RTOSes
Quoted text here. Click to load it
possible).
Quoted text here. Click to load it

It was in my list. I just forgot to mention it.

Josias.


Re: Comments on RTOSes
Quoted text here. Click to load it

The list definitely lacks of

On-Time (www.on-time.com) RTOS-32 (Win32 compatible) for X86
and
their partners ebsnet (www.ebsnetinc.com) RTKernelRISC for X-Scale.

Using RTOS-32 (32bit) for X86 and its predecessor RTKernel (16bit) for more
than ten years now.
Very small footprints possible, very small interrrupt latencies, extremely
good support (f. e. in case you need drivers for special hardware).

Juergen



Re: Comments on RTOSes
Quoted text here. Click to load it

Might consider Sciopta, direct message passing like QNX and OSE.
(I do work for Sciopta)

--
42Bastian
Do not email to snipped-for-privacy@yahoo.com, it's a spam-only account :-)
We've slightly trimmed the long signature. Click to see the full one.
Re: Comments on RTOSes

-SNIP-

Quoted text here. Click to load it

MicroC/OS-II and the uC/FS Embedded File System from Micrium www.ucos-ii.com
meet the requirements you list and it will save you some big $$$.
To meet you medical needs, Validated Software (www.validatedsoftware.com)
offers complete 510K ready Validation Suites for the Micrium products that
are suitable for all classes of medical devices.

Scott



Re: Comments on RTOSes
On 2 Mar 2005 16:00:23 -0800, "Josias R. P. Langoni"

Quoted text here. Click to load it

I have seen lots of warnings from chip manufacturers about their chips
not being used in life endangering or medical instruments. Are any of
those processors disclaimed about that?

Also, I bet the OS vendors also say they are not for use in those kind
of applications. I think you need to study the requirements for
medical instruments and maybe airplane safety requirements. I cannot
believe any OS qualifies for those. When the price is high (ie to life
or legal liability), I think most people go for very simple
applications that can be shown to work.

Regards ~Steve

P.S.> a quote from somewhere on usenet:
   Beware of bugs in the above code; I have only proved it correct,
not tried it.                     -- Donald Knuth


Re: Comments on RTOSes

Quoted text here. Click to load it

You will most likely find that they all have those disclaimers. The message
is that, should you use their devices in such an application without having
their (probably paid) involvement, you cannot declare offload any of your
liabilities onto them. Quite understandable really.
 
Quoted text here. Click to load it

That is certainly the gist of the OS's that I have read terms and
conditions for. Then, you didn't expect that they would accept liability
either did you.

Quoted text here. Click to load it

The OP was, IIRC, developing for the medical sector and so should confine
his search of requirements to that sector. <http://www.fda.gov/ and
<http://www.medical-devices.gov.uk/mda/mdawebsitev2.nsf/webvwSearchResults/0A5E025F3BAC561180256BF100387FD3?OPEN
(sorry about the length of that one - but you might have spent ages on the
site if I only pointed at the top level).

Quoted text here. Click to load it

When implementing a system that is in control of life critical processes,
there is a great deal of effort required in getting the specifications
correct, ensuring that the system structure allows a simple means of
mitigating hazards and that the consequences of any error are minimised to
the point of the risk becoming "As Low As Reasonably Practical". There is a
useful ISO standard about product and production quality in ISO 13485.

You can achieve some quite impressive systems even without the need for an
OS if you and your team are prepared to go that little bit extra and deal
with the underlying system management features that many OS's will probably
not do right for your application. Remember that your development process
needs to be set-out properly (see AQAP150 on <http://www.nato.int/ for a
clue).

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Comments on RTOSes

Quoted text here. Click to load it
chips
kind
life

There are RTOS which are DO-178B certifiable. Not certified though.
This means you can use them and pass the certification but it is up
to you to ensure the whole system is safe, not just the OS.
For instance ucOS is DO-178B level B certifiable.


Re: Comments on RTOSes
Quoted text here. Click to load it

To put it more precisely: They *can* not be certified, simply
because the DO-178B standard doesn't have a concept to certify
a software component, it only allows a complete system
(OS + application) to be certified.

AFAIK there are discussions underway that may enable, i.e.
certification for COTS components in the future, but as of today,
the standard just doesn't support it.


Quoted text here. Click to load it

To my understanding, it means, that the OS (or at least
siginificant parts of it) has been used in a system that
has successfully undergone the certification process. If
such an OS is used again in a to-be-certified system, one
can hope to re-use part (most?) of the efforts made in
the previous certification process. Plus, given that it has
passed once, there is a realistic chance that there are no
hidden obstacles that would prevent it from passing again.

Quoted text here. Click to load it

(There is also LynxOS, which, by these terms, is level A certifiable.)

Rob

--
Robert Kaiser                     email: rkaiser AT sysgo DOT com
SYSGO AG                          http://www.pikeos.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Comments on RTOSes
On Wed, 09 Mar 2005 19:42:19 -0800, Steve Calfee

Quoted text here. Click to load it

Basically that's correct. No self-respecting chip manufacturer or
software tool supplier would claim that their product is suitable for
the development of medical devices in litigation-mad USA. It's like
saying that the car manufacturer should guarantee that their cars will
not kill any pedestrians. The manufacturer has no control over the
targeted use -- except to refuse to sell you their product which they
won't do.

The onus is on the developer to demonstrate that the tool is suitable
for the targeted use -- simple as that.

Ken.
===============================================
Please direct relevant email correspondence to:
       snipped-for-privacy@hotpop.com

Re: Comments on RTOSes

Quoted text here. Click to load it

Ken is correct here. As, rightly so, the hardware and RTOS manufacturers
disclaim liability on the use of their products in life-critical
applications the responsibility is left with the developer. Ken has already
given a good reference to the FDA site and I believe that if you google
through some of my past postings I have given some refs for the MDD sites.
Of course, with the European MDD associated standards they are sold by ISO,
IEC and CENELEC. Your company will need to follow an appropriate
development standard (look up ISO9001 and TickIT).

Your development team should, as a matter of course, whether or not you
need to use an RTOS. Having been involved in the development and
certification of an Anaesthesia Ventilator the design decision against an
RTOS was taken quite early on. The use of Forth for that project enabled
very thorough "metal-up" certification of every component of the software
and there were some nice mitigations built into the hardware as well (good
watchdogging techniques and hard interlocked system sanity checking).

If you develop with the thought in your mind that, should you mess it up,
the big legal guns will take it out on you personally (for the portion you
messed up on) then you will, I am sure, take the most caerful approach.

I have a busy day today but I am regularly trawling through this newsgroup
so any specific questions I will pick up later.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Comments on RTOSes
Quoted text here. Click to load it

One thing to bear in mind is that if your medical product needs approval
then so will the RTOS. Few do.

Ian
--
Ian Bell

Re: Comments on RTOSes

Quoted text here. Click to load it

The FDA does not lay down any requirement for pre-emptive or not in an
RTOS, for a 510K submission. However it is required to demonstrate
that the 3rd Party software is fit for use and that hazards and
mitigations are identified.

After having said that, it may be considered that a pre-emptive RTOS
is less deterministic and so more effort may be required to perform
the hazard analysis properly.

My company have used pre-emptive RTOSes in our products and have
successfully obtained FDA 510K's. In a recently released product we
used the Accelerated Technology's Nucleus RTOS. This a very effective
RTOS for embedded products, and is well supported.

Ken.
=======================================
Please direct all correspondence to:

       snipped-for-privacy@hotpop.com

Re: Comments on RTOSes
On 3 Mar 2005 18:03:34 -0800, "Josias R. P. Langoni"

Quoted text here. Click to load it

Don't know about MDD, but for FDA some information can be found here:

    http://www.fda.gov/cdrh/ode/software.pdf


Also you might want to take a look at the Noblitt & Rueland website
for training:

    http://www.noblitt-rueland.com


It should be noted that for FDA, there isn't a "certification" for
software to be accepted. Mainly because the use of an RTOS or compiler
is targeted for various products. It's actually up to the software
developer to prove that the software tool is suitable for the intended
use in regards to the product. An extreme example of this, would be to
argue that Windows XP would be a suitable Operating System for a heart
machine. Possibly with a very constrained requirement you could
demonstrate this, but in general it would be very difficuilt to
demonstrate because Windows XP wasn't initially written for use in
such an application. If the 3rd Party software has been used in
similar medical devices then this could be used as part of the
justification for acceptance.

Ken.
===============================================
Please direct relevant email correspondence to:
       snipped-for-privacy@hotpop.com

Site Timeline