Connect with us

embedded note

Discussion in 'Electronic Design' started by John Larkin, Sep 24, 2004.

Scroll to continue with content
  1. John Larkin

    John Larkin Guest

  2. Both quality control methods have their place. They tend to expose
    different types of software problems.
     
  3. Tim Wescott

    Tim Wescott Guest

    And neither one can do much of anything in an environment where software
    quality is viewed as "overhead".
     
  4. Joerg

    Joerg Guest

    Hi John,
    Only if the inspection is done by people other than the designers of the
    code. I believe real tests are inevitable and wouldn't release anything
    without that.

    One very good strategy is to employ procedures similar to those for FDA
    filings for medical equipment, 510(k) and PMA filings. These follow
    hazard flow charts and must contain a complete hazard and mitigation
    analysis. It is similar for aircraft equipment. Even for more mundane
    designs it might pay to peek over the fence.

    Regards, Joerg
     
  5. John Larkin

    John Larkin Guest

    I read my own code carefully, several times, and find most of my bugs
    that way. Funny, the ones that are left for testing are usually really
    gross, like instant crashes, and they're not hard to find or fix.
    Certainly.


    John
     
  6. Joerg

    Joerg Guest

    Hi John,
    That is great. I wish most engineers would do that. That would cut
    design review time substantially. Once I asked a group what would happen
    if the valve were in the open position and then the clock to the uC
    would stop for some reason. Loooong silence, a faint "oh shoot..." from
    someone and then weeks of redesign.

    Regards, Joerg
     
  7. I read in sci.electronics.design that Joerg <[email protected]
    Students should be trained on those 'truth table' puzzles you can get in
    cheap books. Then show them how to use them for real.
     
  8. Ken Smith

    Ken Smith Guest


    Its even quicker to just not put the bugs in, in the first place. :>

    There is some truth to it. An extra hour of careful design can save a day
    of debugging.

    I'm about 1/2 way through the software on my current project. The
    comments outnumber the lines of code by about 2:1. When I'm done that
    will be reduced to about 1.5:1.
     
  9. Rich Grise

    Rich Grise Guest

    If you read a little farther (further?) down the article, it mentions
    17 programmers torture-testing a certain piece of code.
    (alt-tab-tab,hilite,copy,alt-tab,paste)
    "While a simple fix took care of the problem, the programmers wanted to
    find a systematic way to eliminate these sorts of bugs. To do so, a
    random group of programmers applied seven questions that would test the
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^
    software routine to the bad fuel-dumping module as well as to other
    modules. In addition to detecting the expected bugs, the programmers
    found 17 previously unknown problems."
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    Err, that. ;-)

    Maybe that's what the guy means by "code inspection". ;-)

    Cheers!
    Rich
     
  10. Joerg

    Joerg Guest

    Hi John,
    Other things they should learn: Good software work requires the writing
    of a document starting from top level, not just a few comment lines in
    the code. Writing that document should not be procrastinated on until
    after the project when the QC guy bugs them and there is no time. How to
    design fail-safe architectures, assuming that those ideal parts they see
    in their books can and do fail. How to anticipate and mitigate the
    weirdest mistakes a user can make.

    Regards, Joerg
     
  11. It takes most people a long time to learn to do that. One of the
    best ways to teach people not to put bugs in their code is to
    subject everything they write to critical inspection by their
    peers. They soon learn that it has to be got right anyway,and
    it's less embarrassing to do it *before* the code review.
    We review every code change, and though sometimes I think the
    "critical" aspect is lacking, it still helps.
     
  12. That's one good selling point for more code reviews. The review comes
    before the product is released. Once the marketing folks have a
    'working' copy, they can cut testing short.
     
  13. Be careful using that as a positive example. We used to call that
    paperwork "FAA appeasement documents" since the design was effectively
    frozen before the analysis was performed.
     
  14. Joerg

    Joerg Guest

    Hi Paul,
    Yes, there is an appeasement factor. But the concept itself is pretty
    good and you have to really think hard about hazard situations that
    could arise. At the end of the day it doesn't matter anyway whether
    something was in the analysis or not. Once an unfortunate incident goes
    from bad to worse it's all in the hands of the legal folks.

    What I find astounding is when I see a design and there is no hazard
    analysis at all. That's scary.

    Regards, Joerg
     
  15. John Larkin

    John Larkin Guest


    Early-on in the system's life, one BART train crashed into another
    because all the redundant safety logic froze when the single crystal
    oscillator clock stopped.

    One of my temperature controllers can do maybe $100K of damage if the
    uP crashes and the PWM output freezes, so I have a one-shot and a
    relay in the heater circuit. If the one-shot isn't refreshed, the
    relay drops. That's on top of the usual software protections. So the
    customer's system software had a bug and would occasionally send me a
    serial command to go to 3000C, which I dutifully tried to do. Fried a
    bunch of expensive systems. I had to build a black-box data logger
    into my code to catch them doing it. Their code was a nightmare of
    patched, uncommented, stuff-commented-out-nobody-remembers-why C++. I
    never did meet, or even get to talk to, the programmers involved; they
    couldn't be bothered. They patched it some more and the problem went
    away.

    John
     
  16. Joerg

    Joerg Guest

    Hi John,
    That is really poor engineering. The least they should have done is the
    electronic equivalent of a dead-man switch. Don't know if they still
    have them but in Europe the train engineer had to push a button
    regularly. If he or she didn't the train would stop. On BART they would
    have needed something like that for the controller. If a certain pulse
    that would have been generated by the firmware failed to appear again
    within x msec the train should have automatically stopped by means of
    uncommitted hardware. It's the basic watchdog concept.
    Did they try to stiff you for the damages caused?

    Regards, Joerg
     
  17. John Larkin

    John Larkin Guest

    Why not make the "document" part of the code source? That way, you
    don't have two separate docs to maintain and keep coherent.

    John
     
  18. Jim Thompson

    Jim Thompson Guest

    I'm fond of flow charts myself.

    Almost twenty years ago I took a Pascal course at the community
    college from some bitch that insisted on "outlining" instead of flow
    charts.

    Since I was taking the course for my own benefit I just ignored her.

    So she gave me an F for the course.

    Got a letter from the dean, named Shirley something-or-other,
    expressing concern for my "academic future".

    So I sent her back a "Surely Shirley" letter, allowing as how she
    needed to pay closer attention to the records... I already had a
    Masters degree ;-)

    ...Jim Thompson
     
  19. That may be because the code inspection, if properly done, occurs before the
    testing.
     
  20. john jardine

    john jardine Guest

    Well he would, cos he'll be making money from pushing code inspection. Bit
    like the year 2000 'bug' or the firewall and virus detection salesmen or
    those fabled '100% certain' code validators.
    Good progs only result from employing clever, wise, well blooded,
    experienced programmers. Good programmers only come about from having made
    lots and lots of embarassing mistakes. The very best programmers
    unfortunately, prefer to spend all their time writing games.
    regards
    john
     
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day

-