The rules specified by content experts may apply for initial operation. However, after a while it may often turn out that the rules should change, for various reasons: the initial specification was not accurate, the operational conditions were changed, the operational requirements were changed based on experience, etc.
Evidence for the need to change the operational rules may be captured automatically, and analyzed statistically, based on data about the operational activity. Activity ended by an incidence may indicate a need to fine tune the rules. This section describes the resilience-oriented activities incorporated in the rule development stage:
These rules may be tested and developed in sessions of routine operation. Operating the system by real operators, initially at the developer's site (alpha) and later at the customer's site (beta), to learn about the activation rate of each rule. Rules of extremely low rate should be examined carefully, because they are liable to change, to denote a hazard, etc.
These rules may be tested and developed in sessions of operating in exceptional situations, subsequent to sessions routine operation. The exceptional situations may be managed by the faking hazards at the admin station.
The goal of alarm rules are to provide unique, informative alarms about a bunch of hazards, thereof preventing alarm flood. The method is by alarm aggregation, based on machine learning. These rules may be tested and developed in sessions of intensive hazard faking by the admin station.
Updated on 26 Mar 2017.