Softwaresafety book or guidline needed

Go To Last Post
24 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Freaks,

is there any good book or guidline out there on how to write software which matches several safety criterias? The book should give introducion on i.e. how to build up redundant variables, how to make an fast periodic RAM/ROM test, instruction test etc. blabla

I couldn't find anything about that topic.

Regards,
Baldrian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MISRA?

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John_A_Brown wrote:
MISRA?

OK. Misra gives me some coding rules.
But what about walking pattern memory test, Abraham test, GALPAT test, data/variable redundancy, CRC checking, internal programm counter blablabla yadayadayada...

Is there any book or guidline about how to realize this out there?

Regards,
Baldrian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Someone will have to explain to me one day what the point of running a test for ROM/RAM integrity is on the same CPU that's being tested. If something's gone wrong why would you expect the test itself to be any more successful than the running code image - it's just another subroutine in the same code.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

RAM tests can be written in such a way as to not use any RAM (I expect, I've done this on 6809 in the past, so it's almost certainly possible on AVR). As far as Flash goes, I'd tend to agree with you, but I have encountered clients who insist on ROM or Flash checks.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But if the RAM has "gone west" what's the likelihood of the execution path getting back to main() and the point where the RAM test is invoked?

Having said that one of the pieces of software I have been most proud of writing in my career is some x86 Asm written factory test stuff for our 80286 and 80386 machines that did RAM testing as it basically involved me having to work out how to do IDT and GDT stuff and switch into and out of protect mode on the x86's. But even at the time it bothered me that to get as far as launching the test itself the RAM had to be working to a certain extent so it wasn't really testing anything but the upper address lines and specific "adjacent bit" faults.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
But if the RAM has "gone west" what's the likelihood of the execution path getting back to main() and the point where the RAM test is invoked?

I guess the RAM test would be the first thing performed, it would almost certainly have to written in assembly language.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It was

Quote:
fast periodic RAM/ROM test

that I was wondering about.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FWIW,

One time I was asked to add memory testing to a design where, upon power up the code first wrote to the RAM 0x55 and 0xAA, then read it back, then wrote the reverse(0xAA, then 0X55) to the ram and read it back to see that the RAM was OK. This was done to EXTERNAL RAM. We tested this with some ram chips that were confirmed faulty with a tester and the micro picked up on it and showed FAILED on the screen.

The point to this is, that I agree with Cliff that testing internal RAM is kinda pointless, Code can check external RAM though.

Testing ROM is a waste of code space.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
"It was... periodic..."

OK, point taken. I thought we'd lapsed into general discussion about RAM tests!
As far as Abraham test goes, is that when you are called upon to sacrifice your second program?[/b]

Four legs good, two legs bad, three legs stable.

Last Edited: Thu. Sep 18, 2008 - 11:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
FWIW,

One time I was asked to add memory testing to a design where, upon power up the code first wrote to the RAM 0x55 and 0xAA, then read it back, then wrote the reverse(0xAA, then 0X55) to the ram and read it back to see that the RAM was OK. This was done to EXTERNAL RAM. We tested this with some ram chips that were confirmed faulty with a tester and the micro picked up on it and showed FAILED on the screen.

The point to this is, that I agree with Cliff that testing internal RAM is kinda pointless, Code can check external RAM though.

Testing ROM is a waste of code space.

Jim


I don't really understand your point, testing internal RAM at reset is certainly possible. Your 0xaa and 0x55 test would, however be a waste of time, since it wouldn't catch a missing A1, for example.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, I think I found allmost everything I need and want to studie for the beginning. Thanks anyway :D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I don't really understand your point, testing internal RAM at reset is certainly possible. Your 0xaa and 0x55 test would, however be a waste of time, since it wouldn't catch a missing A1, for example.

In an AVR true, but I was testing an 8051 design at the time. BUT, if you read the datasheets on the AVR's with external access you can actually use the lower area with a little bit of work.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Check out this application note and example code: AVR998 Guide to IEC60730 Class B compliance with AVR Microcontrollers.

http://www.atmel.com/dyn/resourc...
http://www.atmel.com/dyn/resourc...

It may or may not be exactly what you are looking for, but its a start.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Someone will have to explain to me one day what the point of running a test for ROM/RAM integrity is on the same CPU that's being tested. If something's gone wrong why would you expect the test itself to be any more successful than the running code image - it's just another subroutine in the same code.

Cliff

Chances are if the ROM is corrupt in the CRC routine itself, the CRC routine stil wouldn't return a valid result, but yes it is possible. So your chances of catching a fault are very high, but not 100%. Redundant checks using different algorithms will increase the reliability of the test, as it is unlikely for a fault to result in a pass on both.

As for the RAM test, it is very possible to start a RAM test without relying on any RAM before hand.

One usually does not call into POST routines, they are typically jumped into, only after POST routines pass, is the stack initialized and allowed to be used. If RAM is needed during testing, a small area is tested & verified first, allowing the stack, or any other data to be placed there. Then the remaining RAM is tested using the larger, more complete routines.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

All the times I've looked at the AVR app notes and never seen 998. It looks pretty new (04/08 ), maybe that is why.

I can imagine the following exchange:

AVR Programmer: But, I have been programming these things for 20 years and I have NEVER seen a "stuck" register bit.

German Safety Inspector: Ah, yes, then you can PROVE to me that it is OK?

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One can consider the microcontrollers used in Magneti Marelli ECUs - they do an absolutely paranoid security test.

- CRC on the prom contents
- ram check (inlined, no stack) with read-write test on every byte
- stack check for push-pull at every position on the stack
- integrity test for eeprom (two copies of each data block; any discrepancies and the eeprom is wiped clean)
- eeprom confirmation after every write

Though you should bear in mind that a lot of the prom is tables which can have a devastating effect on an expensive (several thousand pounds, often) engine if their values are corrupted.

Neil

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mike B wrote:
... Guide to IEC60730 Class B compliance with AVR Microcontrollers.

That's exactly what I need. IEC 60730 / IEC60335-1 Class B compliance. And if I'm really unlucky, Class C compliance will be needed. That depends on the "German Safety Inspector".

@Jim: How did you know :wink:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Check out this application note and example code: AVR998 Guide to IEC60730 Class B compliance with AVR Microcontrollers.

That is quite interesting. I'll have to try an implementation to see how much flash is used and how much time. Once done for an AVR of, say, Mega class the mods for other series/models should be very straightforward.

As an old bit-pusher I was interested in the "March B" "walking" test, as I wrote a few of those for 80186 a few ;) years ago. While our "quick" test was quite similar, the "long" test did a check not mentioned there: After each bit was set/cleared, the entire SRAM space was checked to see that not only did >>that<< bit respond correctly, but that no other bit was following the value of the bit being changed. While it was most common to see a series of bits change (e.g., a short in an address line) there were a few traps of a rouge single-bit elsewhere in those early SRAMs. On a production AVR I'd guess that would be even less likely than any SRAM failure. But with modest internal memory sizes on, say, a Mega88 it shouldn't take that long to do the exhaustive test.

IIRC it took about 20 minutes for the "long" test on 384KB of SRAM, which included other passes with random (well, really "non-sequenctial") vs. sequential testing.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
All the times I've looked at the AVR app notes and never seen 998. It looks pretty new (04/08 ), maybe that is why.

I can imagine the following exchange:

AVR Programmer: But, I have been programming these things for 20 years and I have NEVER seen a "stuck" register bit.

German Safety Inspector: Ah, yes, then you can PROVE to me that it is OK?

Jim

Tell him you will prove it for him immediately after he proves to you that there is not a teapot orbiting Mars.

And even if you perform these tests, how do you know that 5 minutes later a bit won't become stuck somewhere?

MISRA and CMI can certainly add quality, but there is also a point at which one is merely feeding an insane bureaucracy.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, there are certain places in the world where such "insane bureaucracy" seems to be very important. Unfortunately, those places are big enough to have significant effect with their "neighbors" and effectively limit imports over a wide area.

If you live in that area or hope to export to that area, there is NOT much you can do.

For example, you have probably heard (mostly bad stuff) about RoHS. Well, there is a replacement coming into effect at the end of this year called REACh. If you liked RoHS, you will LOVE this one. And it WILL effect us, here. It is otherwise known as (EC 1907/2006). It deals with the Registration, Evaluation, Authorisation and Restriction of Chemical substances.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Testing ROM is a waste of code space.

What about testing ROM/FLASH for integrity of contents, usually based on a CRC stored in ROM/FLASH?

Then there is: RAMnesia 8)

I'll believe corporations
are people when Texas executes one.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Anyone still there?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

barnacle wrote:
One can consider the microcontrollers used in Magneti Marelli ECUs - they do an absolutely paranoid security test.
Neil
I have worked on a couple of engine controllers and at one company the self test on both was quite impressive. When figuring out all of the failure modes there were a lot of things to be missed. We checked the code first with LINT and then even more thoroughly with a program the name of which I can't remember, It came from a company in France. At the other company tests were not so stringent.

Keep in mind most of the failures are going to be software bugs that you did not catch and not in the field failures of the processor chips.

http://www.testingstuff.com/