Engineering a Safer World Systems Thinking Applied to Safety by Unknown

Author:Unknown
Language: eng
Format: epub

Safety-Guided Design

267

The controller must be designed to respond appropriately to the arrival of any

possible (i.e., detectable by the sensors) input at any time as well as the lack of an

expected input over a given time period. Humans are better (and more flexible)

than automated controllers at this task. Often automation is not designed to handle

input arriving unexpectedly, for example, a target detection report from a radar that

was previously sent a message to shut down.

All inputs should be checked for out-of-range or unexpected values and a

response designed into the control algorithm. A surprising number of losses still

occur due to software not being programmed to handle unexpected inputs.

In addition, the time bounds (minimum and maximum) for every input should

be checked and appropriate behavior provided in case the input does not arrive

within these bounds. There should also be a response for the non-arrival of an input

within a given amount of time (a timeout) for every variable in the process model.

The controller must also be designed to respond to excessive inputs (overload condi-

tions) in a safe way.

Because sensors and input channels can fail, there should be a minimum-arrival-

rate check for each physically distinct communication path, and the controller

should have the ability to query its environment with respect to inactivity over a

given communication path. Traditionally these queries are called sanity or health

checks . Care needs to be taken, however, to ensure that the design of the response

to a health check is distinct from the normal inputs and that potential hardware

failures cannot impact the sanity checks. As an example of the latter, in June 1980

warnings were received at the U.S. command and control headquarters that a major

nuclear attack had been launched against the United States [180]. The military

prepared for retaliation, but the officers at command headquarters were able to

ascertain from direct contact with warning sensors that no incoming missile had

been detected and the alert was canceled. Three days later, the same thing hap-

pened again. The false alerts were caused by the failure of a computer chip in a

multiplexor system that formats messages sent out continuously to command posts

indicating that communication circuits are operating properly. This health check

message was designed to report that there were 000 ICBMs and 000 SLBMs

detected. Instead, the integrated circuit failure caused some of the zeros to be

replaced with twos. After the problem was diagnosed, the message formats were

changed to report only the status of the communication system and nothing about

detecting ballistic missiles. Most likely, the developers thought it would be easier to

have one common message format but did not consider the impact of erroneous

hardware behavior.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.