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

Groups > comp.arch.embedded > #24639

Re: Safety-Critical Software Design

Show all headers | View raw

On 16-07-17 13:32 , Don Y wrote:
> 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!)

Sometimes similar errors happen with hardware interlocks.

(Anecdote warning:)

Some years ago, an error of mine, combined with such HW interlocks, 
nearly destroyed the dome hatch of the Nordic Optical Telescope, sited 
on one of the Canary Islands. The hatch is a rectangular section of the 
hemispherical telescope dome, about 3 meters wide in the azimuth 
direction and perhaps 6 meters long in the elevation direction and (I 
think) some hundreds of kilograms in weight. The hatch can slide along 
its curved long edges from one side of the dome, where it covers the 
similarly shaped dome opening, up over the peak of the dome to the other 
side, uncovering the dome opening and letting the telescope view the sky.

The hatch is driven by an electrical motor. The control computer can 
send a "close" command or an "open" command, and there are electrical 
limit switches in the fully-closed position and the fully-open position 
which stop the motion.

One night the astronomers had given the command to open the hatch, but 
before it was fully open they noticed that humid mist was blowing in to 
the mountain-top and so they gave the command to close the hatch. The 
computer switched off the "open" command and immediately switched on the 
"close" command. Turned out the motor is of a type that has to be 
stopped before its direction of motion can be reversed; if already 
running in the "open" direction, switching the command from "open" to 
"close" leaves the motor happily running in the "open" direction, but 
energized by the "close" command.

So, after a while, the hatch activated the fully-open limit switch. 
Turned out that this switch is wired to interrupt only the "open" 
command, not the "close" command. So the hatch kept moving in the "open" 
direction until it hit the mechanical stops, which turned out not to be 
strong enough to stop the motion... the result was some bent metal, but 
luckily an engineer was present who could prop up the hatch with some 
wooden beams which kept it from falling entirely off the dome.

(Later analysis of the error revealed that the hatch was originally 
designed to be operated from a manual handset which had two 
press-and-hold buttons, one for "open" and the other for "close. The 
handset also had a small sliding cover such that only one of the buttons 
was accessible and pressable at a time. This ensured that the operator 
could not switch immediately from an "open" command to a "close" command 
or vice versa, and prevented the problem. However, the information had 
not been translated into requirements on the control SW. Bummer. But 
this illustrates that safety is a system property.)

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

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