Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #24638

Re: Safety-Critical Software Design

From Don Y <blockedofcourse@foo.invalid>
Newsgroups comp.arch.embedded
Subject Re: Safety-Critical Software Design
Date 2016-07-17 03:32 -0700
Organization A noiseless patient Spider
Message-ID <nmfmsd$g5j$1@dont-email.me> (permalink)
References <87vb04oo9f.fsf@digitalsignallabs.com> <nmflgc$c3o$1@dont-email.me>

Show all headers | View raw


On 7/17/2016 3:09 AM, Don Y wrote:
> When I design a solution (hardware and/or software), I am ALWAYS
> asking myself:  how can I *break* this?  And, the goal is NOT to
> convince myself that the vulnerability CAN'T HAPPEN but, rather,
> to figure out how I will protect against it happening (as unlikely
> as it may seem!).
>
> And, *record* all of this so its obvious (to yourself and others)
> why you did something that *seems* "impossible".

An actual example of this sort of "can't happen" thinking:

I frequently design products that move mechanisms.  Often, MASSIVE
mechanisms (e.g., 10HP motors).

Invariably, there are limit switches on the extremes of travel.
And, these aren't always "hardware interlocks" but, rather, rely
on software to interpret their state and adjust the motion of
the mechanism, accordingly.  I.e., STOP moving IN THAT DIRECTION
when the limit is reached (you don't want to cut power to the motor
when it hits the limit because you will eventually want to move OUT
of that limit!)

So, the code effectively looks like:
      if (moving_leftward) {
          if (left_limit_switch_entered) {
               stop();
          }
      }
      if (moving_rightward) {
          if (right_limit_switch_entered) {
               stop();
          }
      }
Makes sense, right?

But, it's relatively easy for a motor to be wired incorrectly.
Or, the harness designed without an adequate key.  Or, the
limit switch harnesses to be swapped.  Or...

In these cases, you can run the mechanism out *past* the limit
switch and damage the equipment or personnel ("Yeah, the bed
is in motion but I'm safe -- it will stop at the limit switch
before it reaches me!")

So, I watch *both* limit switches regardless of which direction
the mechanism is traveling.  If I see a transition on the "wrong"
switch, I bring about the STOP *and* throw an error:
   "The mechanism was traveling right and I saw activity on the
   LEFT limit switch!  That's not possible!  Yet, I SAW IT!!"

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Safety-Critical Software Design Randy Yates <yates@digitalsignallabs.com> - 2016-07-17 00:57 -0400
  Re: Safety-Critical Software Design Paul Rubin <no.email@nospam.invalid> - 2016-07-16 23:10 -0700
  Re: Safety-Critical Software Design Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-17 09:16 +0300
  Re: Safety-Critical Software Design Reinhardt Behm <rbehm@hushmail.com> - 2016-07-17 14:38 +0800
  Re: Safety-Critical Software Design upsidedown@downunder.com - 2016-07-17 10:37 +0300
  Re: Safety-Critical Software Design Don Y <blockedofcourse@foo.invalid> - 2016-07-17 03:09 -0700
    Re: Safety-Critical Software Design Don Y <blockedofcourse@foo.invalid> - 2016-07-17 03:32 -0700
      Re: Safety-Critical Software Design Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-07-17 22:49 +0300
      Re: Safety-Critical Software Design Les Cargill <lcargill99@comcast.com> - 2016-07-26 11:20 -0500
  Re: Safety-Critical Software Design Tim Wescott <tim@seemywebsite.com> - 2016-07-17 20:51 -0500
  Re: Safety-Critical Software Design FreeRTOS info <noemail@given.com> - 2016-07-21 10:33 +0100
  Re: Safety-Critical Software Design Les Cargill <lcargill99@comcast.com> - 2016-07-26 11:17 -0500

csiph-web