How do instrumentation engineers prepare the Safety Requirements Specification (SRS) for a SIS system?

Thread Content

SRS plays a decisive role in realizing safety instrument functions. Preparing the Safety Requirements Specification (SRS) is one of the most important activities in the entire lifecycle of a SIS. It provides engineering implementation guidelines for the design of SIS systems, the hardware integration and software configuration of logic controllers, installation and commissioning, as well as operational startup. In recent years, SIS systems have seen rapid development in the chemical industry, with many of them being implemented almost overnight. Virtually all chemical companies now use SIS systems, but to date, few of them have been able to produce something that is crucial for such systems: the Safety Requirements Specification, or SRS. Recently, there has been a growing emphasis on standardizing SRS management. In fact, SRS is an essential component of SIS; in other words, once SIS is implemented, it should be supported by an SRS. To use the words of one expert: “The fact that it wasn’t used in the past doesn’t mean it’s not needed, and the fact that it wasn’t checked before doesn’t mean it won’t be checked in the future.” It is believed that in the near future, SRS will become just as important as SIS. Whenever SIS is inspected, SRS will also be one of the items that must be checked. Let Changhui Instruments explain what exactly SRS is SRS: yunrun.com.cn/tech/2745.html. SRS stands for Safety Requirements Specification (GB/T 21109-2007); it is a specification that encompasses all requirements regarding the Safety Instrumented Functions (SIF) that a Safety Instrumented System must perform ； (The requirements should be very clear). Purpose and content of SRS: To achieve the required safety functions, and in accordance with the specified instrument safety functions (SIF) as well as the related safety integrity levels (SIL) that define the requirements for each SIF, the SRS should consist of the following two main parts: ◆ Safety function requirement specification, which describes the system’s inputs, outputs, and the logic it operates based on. In other words, does it define what each security function (SIF) should do? For example: when the reactor temperature exceeds the set value (350°C), the electric heater is turned off. ◆The Safety Integrity Requirements Specification describes the safety performance requirements (levels) for each function ； In other words, it defines the capabilities that each security function should have or how good it should be. For example: when the reactor temperature exceeds the set value (350°C), it is necessary to ensure that the probability or likelihood of shutting down the electric heater is over 99% ； Input: Description of the security requirement function ； Output: SIS safety requirements, software safety requirements. Purpose of SRS: The SRS serves as the foundation for the design of SIS systems (including preliminary design, detailed design, as well as management throughout the entire lifecycle from design to operation), and it also forms the basis for the final approval of such systems. Therefore, all necessary information must be included to create a complete set of documents. Note: SRS is an important part of the entire safety lifecycle; through SRS, it is possible to understand how to design a Safety Instrumented Function (SIF) and how to integrate these functions (SIFs) into a SIS. Preparatory work for SRS: Before preparing the SRS, the following activities must be carried out (these activities form the basis for an effective specification; otherwise, it would be pointless to create one). It is essential that these tasks are performed effectively and appropriately. Why is it important to emphasize basic preparatory work? If the foundational work is not done properly, any system requirements specification prepared, no matter how much time and effort is invested, is pointless (if the foundation is wrong, everything is wrong)! 1. Conceptual design of the process flow. 2. Hazard analysis and risk assessment (conducting analysis alone does not enhance the inherent safety of the process or system; it is application in subsequent stages that is more important). 3. Determination of the use of non-SIS protection layers; identification of the SIL level when it is necessary in the context of SIF. Key technical documents are required when preparing an SRS. ◆ Information related to the process: 1. Piping and Instrumentation Diagrams (P&ID). 2. Descriptions of process operations. 3. Descriptions of process control, including the design of basic process control systems and strategies for assigning safety instrument systems, control types, operator interfaces, alarm management, and historical data recording. 4. Relevant safety regulations (including requirements at the ** level, as well as those set by industry bodies, provinces, cities, and various other authorities, along with corporate requirements). 5. Documents related to reliability, quality, or environment, as well as technical documents related to operation or maintenance ； ◆Cause-Effect diagram: A cause-effect diagram can integrate safety functions and integrity requirements into a single technical document (it is also possible to gather other requirements such as gauge ranges, setpoints, and operating conditions in one form) ； ◆Logic diagrams serve as a complement to cause-and-effect diagrams, enabling the description of more complex functions that are based on time or sequence (those that cannot be expressed in words or through cause-and-effect diagrams can be described using logic diagrams or logical relationships) ； ◆Process Data Sheet: The process data sheet provides the necessary information for preparing the instrument selection specification. The preparation phase and main body of the SRS are determined based on the full lifecycle of the SIS and as described in point four. SRS is prepared after the preliminary preparatory work is completed and before the design of the SIS system begins. Who will prepare the SRS? As defined in the SRS, it is a specification for safety instrument requirements and also serves as an input document for the design of such instruments; therefore, process control or instrumentation personnel are typically responsible for preparing these safety requirement specifications (although it is not solely the responsibility of the instrumentation team – the hazard and risk assessment team and/or the project team itself can also formulate these requirements). When it comes to responsibility, no discipline wants to take on this \"hot potato.\" However, considering the purpose of the SRS, it is almost inevitable that the task of preparing it falls on the instrumentation team. Of course, it isn’t a task that can be handled by just the instrumentation team alone; a team composed of representatives from process engineering, safety, equipment, electrical engineering, and other fields can work together to prepare it. Precautions for preparing SRS ◆ Technical requirements should be stated as simply and clearly as possible, so that all personnel (those who may use this information at any stage of the lifecycle) can understand every detail of the specifications ； When designing a safety system to prevent or mitigate the occurrence of hazardous events, one should also avoid making the solution overly complex. ◆The specification sheet should be very clear; it should state what is to be achieved, without necessarily explaining how to do it. ◆The specification can be a single document, or it can be a collection of several documents that include procedures, drawings, or company standard management. The main purpose is to ensure that the SRS lists all the functional requirements and integrity level requirements fulfilled by the SIS, including the requirements for the application software. ◆The description should be clear, precise, functionally verifiable, maintainable, and feasible. ◆Avoid any process conditions or SIS operation sequences that have been identified as potentially leading to hazardous situations (SIS is implemented to prevent hazards, but the risks associated with shutdown processes or after a shutdown also need to be assessed). ◆SIS can perform non-safety instrumented safety functions to ensure orderly shutdown or faster startup; these functions should be separated from the safety instrumented functions. Appendix 1: Summary of Information on Safety Requirement Specifications (table format; the number of specified requirements has been increased to 29). I. Requirements for documents to be submitted ◆ Item 1: P&ID – Required. ◆ Item 2: Cause-and-Effect Diagram (C&E) – Required. ◆ Item 3: Logic Diagram – Not required; it can be omitted if the cause-and-effect diagram adequately describes the logical relationships and requirements. ◆ Item 4: Process Data Sheet – All process parameters and requirements related to the sensors and actuators on site must be provided. ◆ Item 5: Process information related to the hazardous events that need to be prevented by SIFs (reasons for accidents, hydrodynamics, final components, etc.). ① Based on the Hazop and Lopa reports, what risks might occur? How does SIF mitigate or suppress these sub-concepts? ②Requirements for the response speed and accuracy of instruments in safety instrumented systems ； ③Special requirements for actuators (such as the fire resistance time of shut-off valves in case of a fire, the sealing level and shutdown time when closing, etc.) ◆Item 6: Requirements for identifying and addressing common failure modes. Detailed requirements: Failures caused by the process itself or common factors (such as corrosion, crystallization, clogging, etc.). All extreme environments that the SIS may encounter must be identified (taking into account factors such as corrosivity, viscosity, and crystallization). A diversified design approach should be adopted as much as possible to avoid common failure modes. ◆Item 7: Legal and regulatory requirements affecting SIS. Detailed requirements: international, **, regulations issued by the General Administration of Safety Supervision, local regulations, official documents, and corporate management requirements. II. Detailed requirements for SIFs (describe all required SIFs to meet functional safety requirements, including instrument safety functions and safety integrity levels). ◆Item 8: SIF numbering. Detailed requirements: This is necessary as a unique identifier for each SIF, facilitating subsequent maintenance and management.
◆ Item 9: Required SIL level for each SIF (the SIL level and operating mode of each SIF). Detailed requirements: SIL0–2; SIL3 is rarely used in the chemical industry.
◆ Item 10: Expected demand rate (possible sources of demand for SIFs and their frequency). Detailed requirements: Whether it’s a low-demand or high-demand mode; in the chemical industry, the low-demand mode is typically employed.
◆ Item 11: Test interval (requirements regarding inspection and testing cycles, i.e., Proof Test Interval). To meet the required SIL level, certain maintenance and testing requirements must be fulfilled. Detailed requirements: This is very important, as it affects the calculation of the SIL level. At the initial design stage of an SIS, the required test interval should be defined so that it can be taken into account during the design process (SIS calculations) ； It should be determined reasonably in consideration of the production and maintenance cycles of the equipment as well as the usage status of the instruments. ◆Item 12: Definition of the process safety status for each identified time period (the specific time requirements to bring the process into a safe state). Detailed requirements: Installation status (is it shut down?) To maintain? Or draining, etc.) ◆ Item 13: Process inputs and their interlock setpoints. Detailed requirements: These can be described together in a Cause-and-Effect diagram (C&E). ◆ Item 14: Normal operating ranges of process parameters and their operational limits. Detailed requirements: These can be described together in a Cause-and-Effect diagram (C&E). ◆ Item 15: Process outputs and descriptions of their actions. Detailed requirements: These can be described together in a Cause-and-Effect diagram (C&E). ◆ Item 16: Functional relationships between process inputs and outputs (including logic and mathematical functions, as well as any required permissions). Detailed requirements: These can be described together in a Cause-and-Effect diagram (C&E). ◆ Item 17: Selection between de-energization shutdown or energization shutdown (actions taken by the SIS system when power or air supply is lost). Detailed requirements: Since SIS systems are designed to be fail-safe, they are typically configured for de-energization shutdown. ◆ Item 18: Considerations and requirements regarding manual shutdown. Detailed requirements: It must be determined whether hardwired manual shutdown switches, independent of the programmable controller, are necessary. ◆ Item 19: The time required for the SIS to bring the process into a safe state. Detailed requirements: The required response times for sensors, logic controllers, actuators, or human operators cannot be determined arbitrarily. ◆Item 20: Requirements for corresponding actions regarding diagnosed faults and any other apparent faults. Detailed requirements: Technical requirements for taking necessary actions to enter or maintain a certain state (Should it be ignored, the system should be stopped, or decisions should be made based on other conditions?) ) ◆ Item 21: Human-Machine Interface (HMI) requirements. Detailed requirements: It is necessary to fully describe the interface between the SIS and the operator, including emergency stop, alarms (pre-shutdown alarms, shutdown alarms, bypass alarms, and diagnostic alarms), bypassing (soft bypass and hard bypass), and time sequence recording. ◆ Item 22: Reset function (requirements regarding the steps and procedures to be carried out during power-up and restart of the SIS). Detailed requirements: All requirements related to the restart process following a shutdown must be specified ； Permissions for the reset switch ◆Item 23: Requirements for diagnostic functions in order to meet the desired SIL level. Detailed requirements: Is it necessary for the system to perform regular self-diagnostics? ◆Item 24: Relevant reliability requirements in case an accidental shutdown poses a risk. Detailed requirements: Sometimes, shutting down the system is not the best option; the risks associated with such shutdowns also need to be assessed, taking into account the maximum allowable rate of accidental shutdowns. ◆Item 25: Failure modes of all sensors and transmitters, controllers, and each control valve. Detailed requirements: The failure modes of the SIS should be defined; a transmitter can be designed to cause a trip condition upon failure or to remove that trip condition upon failure. ◆ Item 26: Maximum allowable rate of spurious trips. Detailed requirements: What is the acceptable rate of spurious trips? ◆Item 27: Override, prohibition, and bypass operation requirements. Detailed requirements: Requirements for manually bringing the process into a safe state should be defined; for example, if it is required that the operator be able to manually shut down a device from the control room or on-site, this must be specified, as well as any independence requirements regarding the manual shutdown switches of the SIS logic solver. ◆Item 28: Functional requirements for application software. Detailed requirements: Special requirements – the requirements for software must be clear, unambiguous, verifiable, testable, modifiable, and traceable.
◆ Item 29: Average repair time of SIFs. Detailed requirements: Requirements regarding the average time required for SIFs to recover after a fault occurs.
Annex 2: Safety requirements in the Safety Requirements Specification (SRS) (excerpted from GB/T 21109.1-2007, Clause 10.3).
1. Descriptions of all SIFs necessary to achieve the safety functions (e.g., descriptions of interlock logic, cause-and-effect diagrams, or logic diagrams) ； 2. Identify and consider the requirements for common cause failures ； 3. Definition of the process safety status for each identified instrument safety function ； 4. The definition of any individual process safety state; when these states occur simultaneously, they give rise to a distinct risk (e.g., overload of emergency storage, multiple depressurizations in the combustion system). 5. The assumed sources for the \"Demand\" and \"Demand Rate\" of instrument safety functions SIF ； 6. Requirements related to the time interval (TI) from the proof test ； 7. The SIS puts the process in a safe state; requirements for the response time (execution time) for each SIF ； 8. Safety Integrity Level (SIL) and operation mode (demand/continuous) for each SIF ； 9. Description of the measurement parameters, range, accuracy of the PID process, as well as the trip point (shutdown set value) ； 10. Description of the output actions and criteria for successful operation of the SIF process (e.g., requirements regarding the leakage rate of the shut-off valves) ； 11. The functional relationships between the process input and output points, including logical and mathematical functions, as well as any required permissions ； 12. Requirements for manual shutdown (requirements for manual shutdown of each SIF) ； 13. Requirements related to power-on or power-off tripping (requirements regarding whether each SIF should shut down when powered on or powered off) ； 14. Maximum allowable tripping rate for each SIF (maximum allowable false shutdown rate) ； 15. Reset requirements after SIF shutdown (e.g., requirements for manual, semi-automatic, or automatic reset of the final components) ； 16. Failure modes for each SIF and required SIS responses (e.g., alarm, automatic shutdown) ； 17. Any special requirements related to the SIS startup and restart procedures ； 18. Security requirements for all interfaces between SIS and any other devices, including BPCS and operators ； 19. Description of the factory operation modes, and identification of instrument safety functions in each operation mode ； 20. Security requirements for applications (software) ； 21. Requirements for override/prohibition/bypass, including written requirements regarding bypass operations, must clearly describe how the bypass is set up and how it is deactivated ； 22. When a fault is detected in the SIS, any actions required to achieve or maintain the safe state of a certain process must comply with relevant specifications, and the impact of human factors needs to be taken into account for any such actions. 23. Regarding the practical average time to repair (MTTR) for SIS, factors such as inventory of repair parts, travel time for personnel, part installation, provisions in service contracts, as well as personnel’s technical capabilities and environmental constraints, must be taken into account. 24. Identification of dangerous combinations of SIS output states to be avoided ； 25. Identification of all extreme environmental conditions that SIS may encounter during transportation, storage, installation, and operation. The following aspects need to be considered: temperature, humidity, pollutants, electromagnetic interference/radio frequency interference (EMI/RFI), vibration/shock, electrostatic discharge, electrical explosion protection zone classification, floods, lightning, and other related factors ； 26. Identification of normal or abnormal operating modes in the process, including the operation of the entire process plant (e.g., startup), as well as individual operational procedures (e.g., equipment maintenance, sensor calibration, or repair). Additional SIFs may be required to address these process operation modes ； 27. Definition requirements for the instrument safety function requirements that any SIF must withstand a major accidental event. For example, during a fire, how long must the shut-off valve remain in operation? 28. A list of input, output instruments, and actuators associated with each SIF, ensuring the uniqueness of tag numbers. Changhui Instrument Network features many original and informative technical articles. Everyone is welcome to visit Changhui Instrument Network