Architecture Evaluation with Scenarios

System qualities that do not correspond to runtime behaviors—modifiability, portability, buildability, and testability—must also be captured as part of requirements-gathering activities, although evaluating them can be more difficult (see Section 12.3, Architecture Evaluation with Scenarios). 

Sharing BPCS field devices with the SIS to achieve a redundant configuration may be acceptable, but requires additional analysis (e.g., ANSI/ISA-84.00.01-2004-1, Clause 11.2.10) to determine whether the shared devices are initiating causes for the hazard scenario under evaluation. Further, the fault tolerance requirements of ANSI/ISA-84.00.01-2004, Clause 11.4, should be examined. If the device is a potential initiating cause for the hazard scenario, it should not be used to meet the fault tolerance requirements. For example, SIL 3 requires a minimum fault tolerance of 1 for the final elements when other criteria of ANSI/ISA-84.00.01-2004, Clause 11.4.4.4, are met, yielding the requirement for a 1oo2 architecture. The control valve cannot be used to meet the fault tolerance requirement, if it is the initiating cause for the hazard scenario under consideration. 

The intention of evaluation scenario 1 (ES-1) is to investigate the behavior of the architecture with respect to the operation types insert, update, and delete (see Fig. 8.8). The scenario assumes a fixed amount of data records (e.g., 100.000) in the system, while the number of data records added, deleted, and updated changes in correlation with each operation (Fig. 8.8, Op. O-Op. 20). Operations reflect commits in the sense of a versioning system and are executed in sequence. 

---