>
> 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.
"Thomas Magma" <somewhere@overtherainbow.com> wrote in message
news:BSPQh.25878$6m4.10468@pd7urf1no...
> 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
>
> "steve" <bungalow_steve@yahoo.com> wrote in message
> news:1175371405.656086.246050@d57g2000hsg.googlegroups.com...
>> On Mar 29, 12:37 pm, "Thomas Magma" <somewh...@overtherainbow.com>
>> wrote:
>>> A while back we had a short seminar on DO-178 and I asked the 'experts'
>>> how
>>> DO-178 dealt with the software in modules from a third party (I used GPS
>>> as
>>> an example). They said that as long as our software treated the GPS
>>> module
>>> as a black box or a slave, that we didn't have to ensure that the GPS
>>> module's software was DO-178. Is this true or still true? What about
>>> modules
>>> in general? I have the standard but can't find the answer anywhere in
>>> it.
>>>
>>> Thomas Magma
>>
>> 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
"steve" <bungalow_steve@yahoo.com> wrote in message
news:1175371405.656086.246050@d57g2000hsg.googlegroups.com...
> On Mar 29, 12:37 pm, "Thomas Magma" <somewh...@overtherainbow.com>
> wrote:
>> A while back we had a short seminar on DO-178 and I asked the 'experts'
>> how
>> DO-178 dealt with the software in modules from a third party (I used GPS
>> as
>> an example). They said that as long as our software treated the GPS
>> module
>> as a black box or a slave, that we didn't have to ensure that the GPS
>> module's software was DO-178. Is this true or still true? What about
>> modules
>> in general? I have the standard but can't find the answer anywhere in it.
>>
>> Thomas Magma
>
> 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.
>
>
Reply by steve●March 31, 20072007-03-31
On Mar 29, 12:37 pm, "Thomas Magma" <somewh...@overtherainbow.com>
wrote:
> A while back we had a short seminar on DO-178 and I asked the 'experts' how
> DO-178 dealt with the software in modules from a third party (I used GPS as
> an example). They said that as long as our software treated the GPS module
> as a black box or a slave, that we didn't have to ensure that the GPS
> module's software was DO-178. Is this true or still true? What about modules
> in general? I have the standard but can't find the answer anywhere in it.
>
> Thomas Magma
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.
Reply by Leif Holmgren●March 30, 20072007-03-30
Thomas Magma wrote:
> They said that as long as our software treated the GPS module
> as a black box or a slave, that we didn't have to ensure that the GPS
> module's software was DO-178. Is this true or still true? What about modules
> in general?
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.
Reply by Not Really Me●March 30, 20072007-03-30
"Thomas Magma" <somewhere@overtherainbow.com> wrote in message
news:3XROh.86851$DN.28461@pd7urf2no...
>A while back we had a short seminar on DO-178 and I asked the 'experts' how
>DO-178 dealt with the software in modules from a third party (I used GPS as
>an example). They said that as long as our software treated the GPS module
>as a black box or a slave, that we didn't have to ensure that the GPS
>module's software was DO-178. Is this true or still true? What about
>modules in general? I have the standard but can't find the answer anywhere
>in it.
>
> Thomas Magma
>
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
Reply by FreeRTOS.org●March 29, 20072007-03-29
"Thomas Magma" <somewhere@overtherainbow.com> wrote in message
news:3XROh.86851$DN.28461@pd7urf2no...
>A while back we had a short seminar on DO-178 and I asked the 'experts' how
>DO-178 dealt with the software in modules from a third party (I used GPS as
>an example). They said that as long as our software treated the GPS module
>as a black box or a slave, that we didn't have to ensure that the GPS
>module's software was DO-178. Is this true or still true? What about
>modules in general? I have the standard but can't find the answer anywhere
>in it.
>
> Thomas Magma
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.
--
Regards,
Richard.
+ http://www.FreeRTOS.org
A free real time kernel for 8, 16 and 32bit systems.
+ http://www.SafeRTOS.com
An IEC 61508 compliant real time kernel for safety related systems.
Reply by Thomas Magma●March 29, 20072007-03-29
>
> 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
Reply by Paul E. Bennett●March 29, 20072007-03-29
Thomas Magma wrote:
> A while back we had a short seminar on DO-178 and I asked the 'experts'
> how DO-178 dealt with the software in modules from a third party (I used
> GPS as
> an example). They said that as long as our software treated the GPS
> module as a black box or a slave, that we didn't have to ensure that the
> GPS module's software was DO-178. Is this true or still true? What about
> modules in general? I have the standard but can't find the answer anywhere
> in it.
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.
--
********************************************************************
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. www.electric-boat-association.org.uk..
********************************************************************
Reply by Thomas Magma●March 29, 20072007-03-29
A while back we had a short seminar on DO-178 and I asked the 'experts' how
DO-178 dealt with the software in modules from a third party (I used GPS as
an example). They said that as long as our software treated the GPS module
as a black box or a slave, that we didn't have to ensure that the GPS
module's software was DO-178. Is this true or still true? What about modules
in general? I have the standard but can't find the answer anywhere in it.
Thomas Magma