System Safety Requirements and Constraints

After the system and component hazards have been identified, the next major goal is to specify the system-level safety requirements and design constraints necessary to prevent the hazards from occurring. These constraints will be used to guide the system design and tradeoff analyses. 

The system-level constraints are refined and allocated to each component during the system engineering decomposition process. The process then iterates over the individual components as they are refined (and perhaps further decomposed) and as design decisions are made. 

As the design process progresses and design decisions are made, the safety requirements and constraints are further refined and expanded. For example, a safety constraint on TCAS is that it must not interfere with the ground-based air traffic control system. Later in the process, this constraint will be refined into more detailed constraints on the ways this interference might occur. Examples include 

1 Train starts with door open Train must not be capable of moving with any door open 

2 Door opens whiie train is in motion Doors must remain closed while train is in motion 

---

Additional system safety requirements and constraints, including those on operations and maintenance or upgrades will be used in the design of the safety control structure at the organizational and social system levels above the physical system. There is no one correct safety control structure what is practical and effective will depend greatly on cultural and other factors. Some general principles that apply to all safety control structures are described in chapter 13. These principles need to be combined with specific system safety requirements and constraints for the particular system involved to design the control structure. 

Four high-level system safety requirements and constraints for preventing the hazard were identified and then refined into more specific requirements and constraints. 

In analyzing an existing organizational or social safety control structure, one of the first steps is to determine where the responsibility for implementing each requirement rests and to perform a gap analysis to identify holes in the current design, that is, requirements that are not being implemented (enforced) anywhere. Then the safety control structure needs to be evaluated to determine whether it is potentially effective in enforcing the system safety requirements and constraints. 

Once the mapping is complete, a gap analysis can be performed to ensure that each system safety requirement and constraint is embedded in the organizational design and to find holes or weaknesses in the design. In this analysis, concerns surfaced, particularly about requirements not reflected in the defined ITA organizational structure. 

The hazards, system safety requirements and constraints, and documentation of the safety control structure for pharmaceutical safety were shown in chapter 7 Using these, Couturier performed several types of analysis. 

These recommendations and those resulting from other thoroughly investigated accidents also provide an excellent resource to assist in generating the system safety requirements and constraints for similar types of systems and in designing improved safety control structures. 

System engineering starts with first determining the goals of the system. Potential hazards to be avoided are then identified. From the goals and system hazards, a set of system functional and safety requirements and constraints are identified that set the foundation for design, operations, and management. Chapter 7 describes how to establish these fundamentals. 

AU the parts of the process described in the following chapters start from the same fundamental system engineering activities. These include defining, for the system involved, accidents or losses, hazards, safety requirements and constraints, and the safety control structure. 

The safety requirements and constraints on the physical system design shown in section 7.3 act as input to the standard system engineering process and must be incorporated into the physical system design and safety control structure. An example of how they are used is provided in chapter 10. 

T vo examples are used in this section one was a demonstration for NASA of risk analysis using STPA on a new management structure proposed after the Columbia accident. The second is pharmaceutical safety. The fundamental activities of identifying system hazards, safety requirements and constraints, and of documenting the safety control structure were described for these two examples in chapter 7. This section starts from that point and illustrates the actual risk analysis process. 

A mapping was made between the system-level safety requirements and constraints and the individual responsibilities of each component in the NASA safety control structure to see where and how requirements are enforced. The ITA program was at the time being carefully defined and documented. In other situations, where such documentation may be lacking, interview or other techniques may need to be used to elicit how the organizational control structure actually works. In the end, complete documentation should exist in order to maintain and operate the system safely. While most organizations have job descriptions for each employee, the safety-related responsibilities are not necessarily separated out or identified, which can lead to unidentified gaps or overlaps. 

One key to having a cost-effective safety effort is to embed it into a system engineering process from the very beginning and to design safety into the system as the design decisions are made. Once again, the process starts with the fundamental activities in chapter 7. After the hazards and system-level safety requirements and constraints have been identified the design process starts ... 

At this point in development, the safety requirements and constraints are documented and traced to the design features used to implement them. A hazard log contains the hazard information (or links to it) generated during the development process and the results of the hazard analysis performed. The log will contain embedded links to the resolution of each hazard, such as functional requirements, design constraints, system design features, operational procedures, and system limitations. The information documented should be easy to collect into a form that can be used for the final safety assessment and certification of the system. 

The safety requirements and constraints on the operators of the local water system were that they must apply adequate doses of chlorine to kill bacteria and must measure chlorine residuals. Stan Koebel, the WPUC manager, and Frank Koebel, its foreman, were not qualified to hold their positions within the WPUC. Before 1993, there were no mandatory certification requirements, and after 1993 they were certified through a grandfathering process based solely on experience. 

STPA (System-Theoretic Process Analysis) [5] is an approach developed by Leveson to identify safety requirements and constraints at the system level. In STPA, the system is seen as a set of control loops (comprising interacting components involving software) which interact with each other. STPA uses the existing... 

The overall objective of this research is to fill this gap and investigate the possibility of verifying safety-critical software against safety requirements and constraints which are derived at the system level by using STPA. To control the associated risk of the safety-critical software, we first need to identify the potential hazards and then demonstrate that a potential hazardous cause carmot occur, i.e., the software cannot contribute to an unsafe state. The main purpose of applying STPA to software in the context of a system in our method is to im-derstand the software hazardous causes early to develop corresponding software safety requirements which should be taken into consideration. The second purpose is to reduce the amount time and effort of safety analysis and verification at the code level. 

STPA is implemented in four steps [6] (1) establish the fundamentals of analysis (2) identify potentially hazardous control actions (3) use the identified potentially hazardous control actions to create safety requirements and constraints and (4) determine how each potentially hazardous control action could occur. In step 1, the safety analyst must identify the accidents or losses which will be considered, hazards associated with these accidents, and specify safety requirements (constraints). After establishing the fundamentals, the safety analyst must draw a preliminary (high-level) functional control structure of the system. In step 2, the analyst has to use the control structure as a guide for investigating the analysis to identify the potentially unsafe control actions. Then he or she translates them to corresponding safety constraints. In step 3, the analj t has to identify the process model variables for each controller (automated controller or human) in the control loop and analyze each path to determine how each potentially hazardous control actions could occur. At the end of the process, a recommendation for the system design should be developed for additional mitigations. 

The safety analysis of safety-critical software provides the safety requirements which need to be tested. Safety verification shall be performed to verify a correct incorporation of software safety requirements [24]. Verification must show that hazards have been ehminated or controlled to an acceptable level of risk. Figure 1 shows the proposed method of software safety verification based on STPA at the system level. The method includes three main step>s (1) safety analysis of software at the system level (2) formalization of safety requirements and constraints and (3) verification and testing at the code level. 

Since safety of software cannot be analyzed without taking into account the system context, we take the advantages of STPA at the system level to construct a method for verifying safety requirements derived at the system level by using STPA. The method starts with safety analysis of software in the context of the system level by using STPA to derive the high-level safety requirements and constraints. The potential hazards identified during STPA will be translated into a set of verifiable safety requirements. The safety verification uses these verifiable safety requirements to prove that the software satisfies these requirements. 

There is unlikely to be a universal set of requirements that holds for every safety control structure beyond a small set of requirements too general to be very useful in a risk analysis. Each organization needs to determine what its particular safety goals are and the system requirements and constraints that are likely to ensure that it reaches them. 

The reengineering process starts with the definition of the hazards to be eliminated or mitigated, system requirements and constraints necessary to increase safety, and the design of the current safety-control structure. Analysis can then be used to drive the redesign of the safety controls. But once again, just like every system that has been described so far in this chapter, the process starts by identifying the hazards... 

Communication of system-ievei, safety-reiated requirements and constraints to and from contractors Update hazard anaiyses and maintain hazard iogs during test and operations... 

Environment requirements and constraints may lead to restrictions on the use of the new system (in this case, TCAS) or may indicate the need for system safety and other analyses to determine the constraints that must be imposed on the system being created (TCAS again) or the larger encompassing system to ensure safety. The requirements for the integration of the new subsystem safely into the larger system must be determined early. Examples for TCAS include ... 

Safety-related constraints should have two-way links to the system hazard log and to any analysis results that led to that constraint being identified as well as links to the design features (usually level 2) included to eliminate or control them. Hazard analyses are linked to level 1 requirements and constraints, to design features on level 2, and to system limitations (or accepted risks). An example of a level 1 safety constraint derived to prevent hazards is ... 

Software need not be treated any differently than the other parts of the system. Most safety-related software problems stem from requirements flaws. The system requirements and system hazard analysis should be used to determine the behavioral safety constraints that must be enforced on software behavior and that the software must enforce on the controlled system. Once that is accomplished, those requirements and constraints are passed to the software developers (through the black-box requirements specifications), and they use them to generate and validate their designs just as the hardware developers do. 

Maintain and use hazard logs and hazard analyses as experience with the system is acquired. Ensure communication of safety-related requirements and constraints to everyone involved in development. 

Together, the safety constraints enforced by all of these system control components must be adequate to enforce the overall system safety constraints. Figure C.l shows the overall theoretical water safety control structure in Ontario and the safety-related requirements and constraints for each system component. 

B5 System Safety It shall be demonstrated that the pre-developed software does not violate safety requirements and/or constraints on the system level. GOTO. .. LLNL, Table 6, B 8... 

To accommodate HCF experimental capabilities, a defined process for the preparation, review, and approval of experiments is established as an important element of facility safety. Experiment control is exercised through a system of administrative procedures that are applied to classify experiments into three broad categories (Class I, II, or III) in accordance with the RCSC charter. In addition, all experiments must be conducted in accordance with the approved Technical Safety Requirements, and potential consequences of conducting the experiment must be bounded by the safety analysis in Chapter 3 of this SAR. Proposed experiments that would exceed either of these constraints must be submitted to the SNL Nuclear Facilities Safety Committee (NFSC) and to DOE/AL for review and approval. 

The enterprise shall establish the models, simulations, or prototypes needed to support requirements definition, analyze the system architecture and design, mitigate identified risks, and thereby ensure that the final product satisfies market needs, requirements, and constraints. This effort supports the assessment of system functional and performance characteristics, producibility, supportability, environmental impact, and human systems engineering issues such as maintainability, usability, operability, and safety. 

---