Comments on RTOSes

One company that I have worked alongside in such projects is MPE (see

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.

Goes without saying in such an application. Yes, they are fairly decent tools to use.

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

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.

Consider Express Logic & ThreadX/NetX/FileX:

-->Neil

The list definitely lacks of

On-Time

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

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

possible).

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

Josias.

-SNIP-

MicroC/OS-II and the uC/FS Embedded File System from Micrium

Scott

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

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.

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.

The OP was, IIRC, developing for the medical sector and so should confine his search of requirements to that sector. and (sorry about the length of that one - but you might have spent ages on the site if I only pointed at the top level).

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 for a clue).

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.

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.

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.

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

Rob

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

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

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

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

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

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.

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

Ian