Searching \ for 'Q: firmware reliability for aerospace applications' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=firmware+reliability
Search entire site for: 'Q: firmware reliability for aerospace applications'.

Truncated match.
PICList Thread
'Q: firmware reliability for aerospace applications'
2000\06\13@145350 by Parker, Kevin L

flavicon
face
Hi all,

I'm developing an aerospace application with a PIC microprocessor.  I've
heard that to absolutely insure reliability, aerospace microprocesors
commonly use involve redundant calculations of critical variables and
continuous checking of both RAM and ROM, all on-the-fly.

Can anyone suggest sources of information about firmware
self-diagnostic/reliability measures in common use in the aerospace
industry?

Thanks in advance,

Kevin

2000\06\13@172155 by Dan Michaels

flavicon
face
Kevin wrote:
........
>Can anyone suggest sources of information about firmware
>self-diagnostic/reliability measures in common use in the aerospace
>industry?

Don;y know this, but another consideration is that you
may need to use military "qualified" parts for your app, so
first check if Mchp parts are so qualified.

Similarly, parts from many many vendors are not qualified for
use in life-sustaining medical apps.

regards,
- Dan Michaels
Oricom Technologies
===================

2000\06\14@060317 by Mark Willis

flavicon
face
Parker, Kevin L wrote:
> Hi all,
>
> I'm developing an aerospace application with a PIC microprocessor.  I've
> heard that to absolutely insure reliability, aerospace microprocesors
> commonly use involve redundant calculations of critical variables and
> continuous checking of both RAM and ROM, all on-the-fly.
>
> Can anyone suggest sources of information about firmware
> self-diagnostic/reliability measures in common use in the aerospace
> industry?
>
> Thanks in advance,
>
> Kevin

Quickly (off the top of my head after a long day involving one battery
in my Palm Pro 'exploding', among other things!  Crack!  Guess a
hydrogen explosion?  No harm to the PPro, the battery case just bulged,
but, MAN, sorta jarring to have a palmtop do that in my pocket...
Anyone want a Duracell AAA, really cheap?  <G>)

You think a LOT about what can go wrong, and try to prevent what you
can, and test and intelligently handle what you cannot prevent.

You do things like testing the CPU, RAM, ROM, test *Everything* - and a
watchdog timer in hardware's a MUST.  These tests will have to be sliced
into little sections, run round-robin and continuously.  You need to
test darn near EACH instruction in the CPU (i.e. you want to have a RET
followed by a Goto RetFailed branch, or a Goto JumpGood followed by a
Call JumpFailed - about the only instruction you cannot test are things
like sleep and reboot style instructions - and you want to then make
sure you don't USE those in the rest of the program.)  You need to
perform bit stuck, address bit stuck, adjacent bit stuck, and so on RAM
tests, this I'd do one test at a time, on one small page at a time, move
the data, run a single step on that page, move the data back.  The ROM,
you checksum a chunk at a shot.  Also put "fences" up in RAM, i.e. for a
16-bit machine put 0xA55A or some such value at each of certain
locations - then verify that none of your fences have been "torn down"
by array boundary problems, along with the other RAM tests.  There're
more (And perhaps since that project there've been more tests designed /
required.)

ROM, you test because Cosmic Ray hits can affect a read;  I'm not sure
if Flash RAM is aerospace certifiable (i.e. please check first!)  A
cosmic ray hit would permanently "dump" the charge, potentially, is my
concern - I'd suspect burning fuses is looked upon with more favor by
the FAA design reviewers, so I'd plan to use OTP parts?

You also have to think about all your variables you use to calculate
(i.e. what happens if a cosmic ray hits and causes a mis-read of, say,
the 'stick' position?  (humor me, I know it's not a stick on commercial
A/C!)  You don't want the airplane to periodically shed the control
surfaces when at speed and they suddenly deflect 90 degrees! - so, you
do things like reading many times and median filtering, then low-passing
filter validated input readings, preload the filters each time the
machine boots with current readings, and it's usualy a *good* idea to
disable outputs whenever you re-start (i.e. THINK about what you're
doing - What do you want the machine to do if a power breaker trips
inflight, or a cosmic ray hit causes a mis-read or a re-boot, or or or
or!?)

Figure out "what can break?"  Devise a test that, if it breaks, causes
the machine to re-boot or display a squawk or otherwise show that
something's wrong.  (You want the maintenance crews to yank the box if
something's going wrong.)

And expect to write the whole thing in assembler, or prove that your
compiler has NO bugs;  Good luck, there.

If you're doing some warning system, make sure you don't create too many
spurious warnings or the pilots will get on your case.

And consider insurance off the bat, probably a needed thing for this
market.

 Mark

2000\06\14@072900 by Andrew Kunz

flavicon
face
>ROM, you test because Cosmic Ray hits can affect a read;  I'm not sure
>if Flash RAM is aerospace certifiable (i.e. please check first!)  A
>cosmic ray hit would permanently "dump" the charge, potentially, is my
>concern - I'd suspect burning fuses is looked upon with more favor by
>the FAA design reviewers, so I'd plan to use OTP parts?

I have a friend who works for NASA/JSC.  Part of his job is to qualify hardware
for use on the Shuttle.

Last we talked, the Xircom PCMCIA LAN cards were the only ones to pass the
tests.  Qual was done in Indy, I believe.

Andy

2000\06\14@113420 by Daniel Hart

flavicon
face
Kevin,
IIRC microchip doesn't manufacture mil grade parts, but if you can resolve
the temperature, vibration, and radiation hassles, the firmware reliability
is typically resolved with redundant processors, memory etc. The PIC is
probably not the best choice for this application.
Dan

----- Original Message -----
From: "Parker, Kevin L" <spam_OUTParkeKL1TakeThisOuTspamCH.ETN.COM>
Subject: [PICLIST] Q: firmware reliability for aerospace applications


I'm developing an aerospace application with a PIC microprocessor.  I've
heard that to absolutely insure reliability ...

2000\06\14@120354 by Don B. Roadman

flavicon
face
On 14 Jun 2000, at 11:31, Daniel Hart wrote:

> Kevin,
> IIRC microchip doesn't manufacture mil grade parts, but if you can
> resolve the temperature, vibration, and radiation hassles, the
> firmware reliability is typically resolved with redundant processors,
> memory etc. The PIC is probably not the best choice for this
> application. Dan
>
Yeah, I remember a particularly onerous project from 20 years ago.
They gave us a PPL (preffered parts list) There wasnt much on it
but transistors and some really really old ass IC's. If we couldnt
use a particular part from the early 60's (this was in the 80's) We
had to fill out a boat load of papers and wait interminably to get
approval to deviate from the PPL. Finally, we ended up
implementing the whole damn thing with transistors, and no logic
circuits more complex that those available in 1968. It was a huge
stinking mess, but the Govt was finally happy and all those
gleaming white porcelain chips did look good!

FWIW, I quit the project before the end. It failed miserably, and I
and one other engineer (two said to hell with them) went to fix it,
which we did. At that point, they didnt give a damn what we used
any more PPL or not.

2000\06\14@121014 by Don Hyde

flavicon
face
I am aware of at least one person who is actively building an "aerospace"
application utilizing a PIC, and have seriously contemplated doing so
myself, so I spent a little time talking with him about it at his booth at
EAA's Sun 'n Fun flyin a month or so ago.

His application is an altitude lock for the autopilot he has been marketing
for several years to the experimental aircraft market.  There are several
levels of certification and non-certification for electronic devices for use
in aircraft, and his autopilots are strictly in the experimental category,
where it is pretty much up to the builder-owner of the aircraft as to what
standards most of the instruments need to comply with.

The FAA has many specifications, some of them very specific to a particular
instrument such as an altimeter, and some much more general ones such as (I
think I'm remembering the number correctly, but I am over 50, you know)
DO-178B which specifies how software is to be tested for various levels of
life-criticality.

A few FAA specifications are available for free from their website or from
the gov't printing office, but most of them are maintained by a private
firm, which charges quite substantial fees for copies (As I recall, it is
several hundred $$$ for DO-178B).

If you are interested in pursuing avionics development, I would suggest
joining the EAA (expreimental aircraft association), which is a member of
the consortium that controls that FAA-document-controlling private firm.  A
couple of years ago when I had more spare time and was actively trying to
learn how to build electronic instruments, I contacted the home office of
the EAA, and found that, while most of their members were more interested in
building airplanes, there were a few who were interested in the gizmos on
the panels, and the organization was interested in helping them obtain the
necessary documents.

Aviation is very strange.  It has its commercial side which is incredibly
bogged down in FAA red tape, insurance, and lawyers -- to the extent that
Cessna has three lawyers for every engineer on their staff.  The commercial
builders make one or two hundred small planes a year.  And then there's the
"experimental" homebuilt side, where you can build just about anything you
want, and if you can convince one inspector that it will fly and not kill
you or some bystander, you can get it licensed as a real airplane.
Homebuilders build one or two thousand small planes a year.

> {Original Message removed}

2000\06\14@124214 by Todd Carrico

picon face
>
> The FAA has many specifications, some of them very specific to a
particular
> instrument such as an altimeter, and some much more general ones such as
(I
{Quote hidden}

in
> building airplanes, there were a few who were interested in the gizmos on
> the panels, and the organization was interested in helping them obtain the
> necessary documents.
>
> Aviation is very strange.  It has its commercial side which is incredibly
> bogged down in FAA red tape, insurance, and lawyers -- to the extent that
> Cessna has three lawyers for every engineer on their staff.  The
commercial
> builders make one or two hundred small planes a year.  And then there's
the
> "experimental" homebuilt side, where you can build just about anything you
> want, and if you can convince one inspector that it will fly and not kill
> you or some bystander, you can get it licensed as a real airplane.
> Homebuilders build one or two thousand small planes a year.
>

There is far more room for inovation in the Experimental category.  These
airplanes are faster (and slower depending on your taste) than the factory
built.  Most of the technology that the factory is putting in is from the
60's.

A lot of the builders are engineers, and not afraid of challenges.  I know
of
a couple of "projects" using PIC's to monitor engine funtions, homeade
autopilots, specialized safety systems, etc.  These people are very
interested
in doing things better, safer, and cheaper.

http://www.eaa.org I think

tc

2000\06\16@055433 by Dan Michaels

flavicon
face
Kevin wrote:
........
>Can anyone suggest sources of information about firmware
>self-diagnostic/reliability measures in common use in the aerospace
>industry?

Don;y know this, but another consideration is that you
may need to use military "qualified" parts for your app, so
first check if Mchp parts are so qualified.

Similarly, parts from many many vendors are not qualified for
use in life-sustaining medical apps.

regards,
- Dan Michaels
Oricom Technologies
===================

More... (looser matching)
- Last day of these posts
- In 2000 , 2001 only
- Today
- New search...