Comments on RTOSes

Josias R. P. Langoni wrote:

-SNIP-

>> 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.

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 

Josias R. P. Langoni wrote:
> Sorry for replying to myself. I appreciated the inputs. Though it's
> great having so many choices, it makes life hard when one has to make a
> decision. That's why I tend to narrow my search on those RTOSes I
> mentioned in my post.
> 
> I wonder if there is no person that worked with one of those brands
> willing to share their experience with them as it's hard to figure out
> the real virtues and limitations of such products base only upon
> manufacturer's catalogues or websites. For instance, from what I could
> learn from reading their website I wasn't quite impressed by VxWorks
> (5.x) as far as development tools are concerned though AFAIK it is one
> of the main if not the main player in RTOS and related stuff market.

We are working with QNX, RTAI-Linux and Integrity. From a technological 
point of view we found that QNX is the most flexible RTOS. It is 
scalable without any kernel modification from a full blown standalon 
real-time operating system with SMP support to a deeply embedded RTOS 
for automotive and medical applications. Because of its own windowing 
system 'Photon' and XFree86 support, it has also a lot of features for 
desktop applications. The support of x86 desktop systems is outstanding 
... the Eclipse IDE works on top of QNX6 (self hosted), Windows and Linux.

  Best Regards

     Armin

     http://www.steinhoff-automation.com


> 
> Thanks again and my best regards.
> 
> Josias.
> 

On 2 Mar 2005 16:00:23 -0800, "Josias R. P. Langoni"
<jrplangoni@yahoo.com> wrote:

>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).
>

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

Steve Calfee wrote:

> 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?

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.
 
> Also, I bet the OS vendors also say they are not for use in those kind
> of applications. 

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.

> I think you need to study the requirements for
> medical instruments and maybe airplane safety requirements. 

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).

> 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.

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).

-- 
********************************************************************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/
********************************************************************

Steve Calfee wrote:
> 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.
>

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.

In article <1110557076.412529.151620@z14g2000cwz.googlegroups.com>,
	"Lanarcam" <lanarcam1@yahoo.fr> writes:
> 
> There are RTOS which are DO-178B certifiable. Not certified though.

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.


> 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.
> 

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.

> For instance ucOS is DO-178B level B certifiable.

(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
Klein-Winternheim / Germany       http://www.sysgo.com

On Thu, 03 Mar 2005 22:45:29 +0000, Ian Bell <ruffrecords@yahoo.com>
wrote:

>Josias R. P. Langoni wrote:
>
>> 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).
>> 
>
>You have not mentioned if any of these products need to meet FDA or MDD
>requirements.  If they do then you may not be able to use a pre-emptive
>RTOS.
>
>Ian

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:

       kenlee@hotpop.com

On 3 Mar 2005 18:03:34 -0800, "Josias R. P. Langoni"
<jrplangoni@yahoo.com> wrote:

>Would you mind to hint where in FDA standards and MDD should I look at
>to find the articles that support this statement? We have other persons
>taking care of standards and certication but I assumed (I come from
>telecom) using a preemptive RTOS wouldn't be an issue (RTOS
>manufacturer ads seem to support this assumption.) If it turns out to
>be an issue, we'd get to it eventually but not before wasting time.
>
>TIA
>
>Josias.

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:
       kenlee@hotpop.com

On Wed, 09 Mar 2005 19:42:19 -0800, Steve Calfee
<stevecalfee@hotmail.com> wrote:

>On 2 Mar 2005 16:00:23 -0800, "Josias R. P. Langoni"
><jrplangoni@yahoo.com> wrote:
>
>>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).
>>
>
>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

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:
       kenlee@hotpop.com

Ken Lee wrote:

> 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 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.

-- 
********************************************************************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/
********************************************************************