Safety requirement specification input

The design basis includes the process requirements specification and the safety requirements specification. The process requirements specification is typically developed by process engineering, with input from operations personnel. The process requirements are provided to the instrumentation, electrical, or controls systems personnel to develop the safety requirements specification with input from operations and maintenance personnel. 

Prior to carrying out SIL verification calculations for Safety Instrumented Functions (SIF) it is essential and very important that each function and its associated input and output signals be weU defined. The identification of the SIF is part of the analysis phase and the detail requirements for each function are documented in the Safety Requirements Specifications (SRS). 

The safety requirements specification is followed by SIL assignments in the safety lifecycle. In order to fulfill a complete SRS, the required safety input information should be accessible. A typical set of input information includes process conditions, existing hazards, required SISs, required SIFs,... 

The starting point for an SIS is the safety requirements specification or SRS. If we look at the input requirements for developing an SRS, we will see that much of the information needed stems from a good knowledge of the manufacturing process, its normal operations, and its potential hazards. 

Case 1 employs a dual loo2 sensor pair as inputs to a single channel logic solver with diagnostics, lool D. A dual redundant pair of valves is used to shutoff feed to the process. The safety requirements specification for this function calls for SIL 2 integrity to protect against the hazardous condition that could arise as much as once per year (i.e D =l/yr). 

The object and collaboration diagrams are input to the OF-FMEA method. From this input we develop formal specification of component interactions. For this purpose we use CSP. Each component of the collaboration diagram becomes a CSP process with input and output channels as shown in the diagram. In addition to this we develop formal models of safety requirements of the system. The requirements are derived from the railway safety regulations. Each requirement is modeled as a CSP process and imposes some restrictions on the ordering of events in the system. The requirements refer to the events that are visible on Level 4 of our decomposition. 

Formal specifications that were positively verified against the safety requirements are the input to the next step, the analysis of component failures. 

Before starting the SIS realisation phase, the overall safety requirements have been previously developed, as well as the SR allocation and specification. The following inputs are then available ... 

The input to the specification of the software safety requirements for each SIS subsystem shall include... 

Verification Activity of demonstrating for each phase of the relevant safety life cycle by analysis and/or tests, for specific inputs, the outputs meet in all respects the objectives and requirements set for the specific phase. 

A-15. Verify that the PSW functions that are not required by the safety system requirement specifications caimot be invoked and adversely affect the required functions, for example through erroneous inputs, interruptions and misuses ... 

In any event, even if the specification is expressed mathematically, this does not preclude it being incomplete. Incompleteness poses problems at all levels but particularly so for safety requirements. It would be unfortunate if conditions arose which could precipitate an accident and the code to deal with the consequent inputs was absent from the program because of omissions in the specification. Completeness with regard to the safety requirements should arise out of the results of the hazard analysis, but unfortunately this cannot always be guaranteed. 

The safety requirements must correctly reflect the critical properties of the environment in which the software is to operate. This is of importance since the software system may react differently in different environments and it is imperative to exercise the programs with representative inputs. In practice, general user requirements will change over a period of time and a necessary feature of the safety specification will provide for maintainabihty of the safety systems so that the achieved safety level is not compromised by future alterations. 

This book hsffi been arranged into 17 dtapters. The first dtree deal with general concepts and principles of plant layout from basic technology and input requirements to actual deliverables. Plant layout specifications have been included for spacing, clearances, and safety requirements leading to equipment arrangement... 

This step aims to verify the software at the code level against the safety requirements which are expressed in the formal specification in step 2. After formalizing the safety requirements, this step can be done in two different ways 1) using a model checker for formal verification [22], or 2) using a model checker to generate corresponding test cases [17]. A model checker takes as input a model of the software and the property of interest, which is written in temporal logic and... 

The requirements specifications of monitoring and control systems often demand high levels of performance from a computational system. For example, the computational task may involve real-world data acquisition, combinational or sequential logic functions, complex arithmetic calculations, and the generation of control outputs to the application plant. The computational response may be required within very tight time constraints, perhaps as part of a real-time schedule. The schedule may have to be maintained in the presence of asynchronous external inputs, such as operator commands or alarms. In addition, the system may have to perform safety functions or functions with safety implications. 

Each safety case is subordinate to its corporate safety management system (SMS), but used nevertheless to interact with the SMS. This results in each safety case, based on a specific part of the company s operation, using the SMS to assure and control hazards and receiving much of its input from narrowly scoped safety assessments. Furthermore, the safety case should provide safety requirements/input/criteria for any future modification to the platform via the safety management systena. 

Other activities that fall within the area of postmarketing surveillance require input from, if not handling by, those responsible for clinical drug safety. These may include observational (non-interventional) studies, which may be retrospective or prospective, and other projects specifically designed to investigate a safety issue. 

---