Monday 23 March 2020

Triplet Behaviour Concerns

Triplet enactment concerns address failures in enacting a triplet; triplet behaviour concerns address failures in the governed behaviour of a correctly enacted triplet. This post lists only a few behaviour concerns, with brief comments on each. There are many more: every project should establish and maintain its own checklist of particular concerns.

BREAKAGE: Domain interaction protocols must be correctly observed. For example, in a lift system a minimum settling time is stipulated between stopping and restarting the hoist motor, and a longer time if direction is reversed. Ignoring this rule may damage or even break the motor.

CREEP: Suppose the program variable p records the linear position of a robot arm P: p:=posn(P) sets p to the sensed position of P, and moveTo(P,p) moves P to the recorded position p. Conversion between the real physical position of P and the floating-point value of p is unavoidably approximate. The sequence {p:=posn(P);moveTo(P,p)} may change the position of P, perhaps with a bias in one direction. Over time, repeated execution of the sequence, with no other assignments to p and no other moves of P, may cause the arm position to creep. A detailed analysis of creep—in temporal rather than spatial position—is given in a report [1] on a failed critical system.

CRITICAL PRIORITY: In identifying the requirements are relevant to a triplet, global requirements should be treated with scepticism. For example, the apparently global requirement "The lift doors are never open while the lift is moving" may not apply to firefighter mode operation: a firefighter's need to escape from a burning floor takes precedence over the more general safety requirement.

DORMANT RESPONSE: When a triplet behaviour has entered a waiting state, it may later execute a delayed action that is no longer appropriate. For example, when the driver presses the brake pedal on the highway, the Cruise Control behaviour goes into standby mode, waiting for the driver to press the Resume button. If, after joining slow urban traffic, the driver presses the Resume button by accident, the resulting acceleration will be very dangerous and possibly fatal.

RACE CONDITION: A race condition exists between two temporal phenomena—each an occurrence of an event or of a state value—whose ordering is indeterminate. A race may be harmless: for example, an empty waiting lift may be summoned almost simultaneously by requests from a floor above and a floor below, and will then depart in the direction of the 'winning' request. In general, races are unavoidable because the governed world has independent agents and processes that cannot be prevented from racing in competition. Addressing a race condition concern means ensuring that neither outcome can cause serious failure. A lethal race condition is described in [2].

[1] US GAO Report; GAO/IMTEC-92-26 Patriot Missile Software Problem; February 1992.
[2] Nancy G Leveson and Clark S Turner; An Investigation of the Therac-25 Accidents; IEEE Computer 26,7 July 1993.

Links to other posts:
 ↑ Avoiding Failure: Checklists of failures and how to avoid them
 ↑ Triplets: Triplets (Machine+World=Behaviour) are system behaviour elements
 ← Triplet Enactment Concerns: Failures to avoid in triplet enactment design

No comments:

Post a Comment