How does DO-178 treat OEM modules (with software)?

This doesn't sound right and I suspect that the 'expert' had misunderstood the full import of your question. I have no authoritive answer for you but I would have looked at the consequences of reading the wrong information from the module or the module performing the wrong action in a HAZOP study. The results of that study would have pointed the way for you to consider the treatment of COTS modules.

I can see both sides to the argument. The two extremes would be using a GPS module for autopilot or just displaying the time on a clock in the bathroom. In the latter, if one was to claim his 'clock system' as DO-178 compliant does that mean he has to try to force the GPS OEM to be DO-178 compliant? Something that wouldn't happen.

Thomas

Huh? Sounds very wrong to me.

By 'module' are you talking about a separate piece of hardware with no physical coupling running its own software. Or are you talking about a software module that will run on the same piece of hardware as your own software. In either case if the 'module' is used in flight you really do need to worry about its compliance.

There are allowances in DO-178B for using commercial-off-the-shelf (COTS) software in a certified product, but only at safety level D. This essentially would be for a avionics product could not result in the loss of the aircraft. Higher levels of safety, i.e., Levels A, B and C can not use untested software, either as part of an application or in a module that is used in the application.

DO-178B software levels (A, B, etc.) are based on the potential of the software to cause safety-related failures identified in the system safety assessment. DO-178B has five levels of certification: Level A: Software whose failure would cause or contribute to a catastrophic failure of the aircraft. Level B: Software whose failure would cause or contribute to a hazardous/severe failure condition. Level C: Software whose failure would cause or contribute to a major failure condition. Level D: Software whose failure would cause or contribute to a minor failure condition. Level E: Software whose failure would have no effect on the aircraft or on pilot workload.

Scott Validated Software

As elsewhere stated they must have misunderstood your question if they really were experts. I'm no expert and have not had to deal with this for a few years but:

Depending on the criticallity level you have to fulfil it may be your problem or only your suppliers problem, but it will be somes for sure.

As far as I remember however if you have two components running on the same hardware (computer) where one has higher criticallity level you will have to have mechanisms to make sure that the less critical piece of code does not mess around with the more critical. Without having looked into this too much I would say that calls for special hardware architecture with memory protection and so on, which of cource would end up in the higher criticallity bin.

It can go either way, there is no doubt that there is DO-178 Level A certified SW out there that contains modules that have untested (in the formal sense) software/firmware. These modules can be separate HW modules or preprogrammed chips within the Level A HW itself.

Effectively you are looking at the module like a black box as the "experts" claimed, whether it has software it it, or firmware, or PLD code or logic gates to implement the task, is irrelevant.

There are a few key elements, one is that is it a slave to the Level A SW? In that if it failed the Level A SW could handle the failure, either by selecting an alternate input (another GPS module) or use a secondary input.

The second is could the slave take down the Level A SW (say by continuously toggling an interrupt to the Level A HW). You have to assume normal failure modes in this case. Additionally you have to think about if some software programmer intentionally wanted to corrupt/take down the Level A HW, could he do it? If the answer is yes then that module has to be Level A.

The dumber and fewer interconnects between the module and the Level A SW the better.

Thanks Steve,

This is what I was kind of thinking. It is hard to know what is really inside third party components or modules. So it is really not practical for a QA department to go knocking on each and every component/module manufactures door asking them if they have software or firmware in their device and then scraping your own design approach because you found one that wasn't DO-178 compliant.

I just wish I could find somewhere in the spec that addresses this issue.

Thomas

Take a look at the FAA WEB site. I seem to recall there are some papers available on the topic. Here is a start:

...

Please do not top-post. Your answer belongs after (or intermixed with) the quoted material to which you reply, after snipping all irrelevant material. See the following links: