Application software safety requirements specification

The overall SIS architecture may impose additional functional software requirements to the specified safety instrumented functions. A typical example is the 1oo2 selection logic for redundant sensors as well as a specified safe action on detection of a dangerous failure by sensor self-diagnostics. Examples given in Annex B list those requirements originated from the applied architecture. [Pg.53]

The application software should also take into consideration the diagnostics provided by the PES and be developed to take the appropriate actions defined in the logic solver safety manual. [Pg.53]

No reproduction or networking permitted without license from IHS [Pg.53]

The detailed functional safety requirements specification should include all necessary functions during all modes of operation of the process being protected. Additionally, the periodic testing of all the safety instrumented functions should be provided. This typically requires the definition of maintenance override capabilities so the sensors and final elements can be tested without shutting down the process. The same methodology described in the paragraph above can be used to document these requirements. [Pg.54]

If multiple SIS are used to implement safety instrumented functions, documentation should be provided to explain which functions are to be implemented in each SIS. If multiple SIS are used to implement the same safety instrumented function then the interaction and independence of each SIS should be documented. This documentation should include the expected SIL that should be provided by each SIS. [Pg.54]

1 The objective of this ciause is to provide requirements for the specification of the appiication software safety requirements for each programmable SIS subsystem necessary to implement the required safety instrumented function(s) consistent with the architecture of the SIS. [Pg.75]

Hardware architecture Software architecture (s/w architecture consists of embedded s/w and applications s/w) [Pg.75]

Generic and application specific features in hardware Examples include - diagnostic tests - redundant processors - dual I/O cards Embedded software Application software [Pg.75]

1 An application software safety requirements specification shall be developed. [Pg.75]

NOTE 1 An SIS usually consists of three architectural subsystems sensors, logic solver and final elements. Furthermore, subsystems could have redundant devices to achieve the required integrity level. [Pg.75]

NOTE 3 The application software safety requirements specifications may be included as part of the SIS safety... [Pg.70]

Application software safety requirements specification To specify the requirements for the software safety instrumented functions for each SIS function necessary to implement the required safety instrumented functions 12.2.2 SIS safety requirements specification Safety manuals of the selected SIS SIS application software safety requirements specification Verification information... [Pg.73]

Application software safety validation planning To develop a plan for validating the application software 12.3.2 SIS application software safety requirements specification SIS application software safety validation plan Verification information... [Pg.73]

Application software design and development Architecture To create a software architecture that fulfils the specified requirements for software safety To review and evaluate the requirements placed on the software by the hardware architecture of the SIS 12.4.3 SIS application software safety requirements specification SIS hardware architecture design manuals Description of the architecture design, for example, segregation of application S/W into related process subsystem and SIL(s), for example, recognition of common application S/W modules such as pump or valve sequences... [Pg.73]

Application software design, and development. Support tools and programming languages To identify a suitable set of configuration, library, management, and simulation and test tools, over the whole safety life cycle of the software (utility software) 12.4.4 SIS application software safety requirements specification Description of the architecture design Manuals of the SIS List of procedures for use of utility software Verification information... [Pg.73]

The application software safety requirements specification shall provide information allowing proper equipment selection. The following shall be considered ... [Pg.76]

Application software safety requirement specification Requirements of specification for software SIFs for each SIS function required for SIFs. Software safety integrity for each SIF allocated to that SIS. 12.2.2... [Pg.458]

The application software safety requirements should be developed as a traceable response to the SIF safety requirements specification. Factors to be addressed include ... [Pg.54]

Determine the proper execution order of the networks and logic, within each program and the execution sequence and desired execution rates of all the application programs. Confirm that the execution rates of the application programs are consistent with the required process response times from the software safety requirements specification. [Pg.59]

Each SRCF specified in the software safety requirements specification, and all the application software based SRECS operation and maintenance procedures shall be validated by test and/or analysis. [Pg.258]

The objective of this clause is to demonstrate that the application software meets its software safety requirements specification when running on the hardware and embedded software used in the SIS subsystem. [Pg.83]

Prior to development of the application software, the user provides a process risk and hazard assessment which is used to identify the software safety requirements in terms of the safety instrumented functions and their SIL. Once the decision to implement the safety instrumented functions in software is made, any conflicts, discrepancies and omissions in the safety requirements specification which come to the attention of the software designers should be addressed. One example might be the effect of the order of execution of the safety instrumented functions within the software. Another example would be the response of the application software as it relates to energy outages. [Pg.54]

The specification of the requirements for application software safety shall be sufficiently detailed to allow the design and implementation to achieve the required safety integrity and to allow an assessment of functional safety to be carried out. The following shall be... [Pg.76]

If previously developed application software library functions are to be used as part of the design, their suitability in satisfying the specification of requirements for application software safety (see 12.2) shall be justified. Suitability shall be based upon... [Pg.79]

Is the final design checked against the safety requirements specification by an independent person prior to programming the application software ... [Pg.97]

Confirm that the application software meets the requirements established in the safety requirements specification under all expected operating conditions. Consider the following ... [Pg.220]

ANSI/ISA-84.01-1996 requires that the application software be developed in accordance with the Safety Requirements Specification (SRS). ANSI/ISA-84.00.01-2004-1 also requires this, but discusses the development of the application software with relation to the safety lifecycle. Where hardware is prone to random failures, the software is more prone to systematic failures. The safety lifecycle is important, because it is the primary mechanism for reducing systematic failure. The inclusion of the lifecycle discussion in the software section does result in repetition of the design process described in ANSI/ISA-84.00.01-2004-1 Clause 11. This repetition is intended to highlight the importance of the lifecycle in the development, verification and validation of application software. ISA-TR84.00.04-1 Annex O provides a discussion of the evolution of application software development. [Pg.251]

Application software safety specification (Clause 12.2) Typical SIS sub-system architecture in line with the requirements of lEC 61511 has been shown in Fig. VI/5.3.2-1. [Pg.456]

Major requirements for application software safety specification may be as follows ... [Pg.456]

Gather the requirements for the systems including functional (e.g. operational checks) requirements, nonfunctional (e.g., coding standards) requirements, users, company-wide regulatory compliance (e.g., Part 11 technical control), safety, process, and other applicable requirements Characterize information, assess its value to the organization, and incorporate information quality as part of the project plan Conduct a system (hardware, software, and process) risk analysis. New requirements may be found as the result of the risk analysis. Any new requirements must be documented in the requirements specification deliverable... [Pg.40]

Software hazard analysis (SWHA) is a system safety analytical technique whose primary function is to systematically evaluate any potential faults in operating system and applications software requirements, codes, and programs as they may affect overall system operation. The purpose of the SWHA is to ensure that safety specifications and related operational requirements are accurately and consistently translated into computer software programs. In this regard, the analysis will verify that specific operational safety criteria, such as failsafe or fail-passive, have been properly assimilated into operational software. The SWHA will also identify and analyze those computer software programs, routines, or functions that may have direct control over or indirect influence on the safe operation of a given system. Also, in the operation of the computer software command function, there is a potential that the actual coded software may cause identified hazardous conditions to occur or inhibit a desired function, thereby creating additional hazard potential. [Pg.179]

The process for the specification of human subsystem safety requirements is no different to software or hardware although it is ai uably considerably harder due to the difficulties associated with the immense scope and variety of issues affecting the reliable performance of human tasks. This paper has examined issues relating to the consideration of human subsystem safety and has outlined the scope and activities necessary for a comprehensive human factors safety analysis. A pragmatic method was introduced that advocates the application of focused Human Factors techniques to the assurance of safety for human subsystems. [Pg.22]

The relative difficulties associated with the specification, implementation, validation and verification of human safety requirements, compared with safety requirements for hardware and software, should not be underestimated and this paper has not addressed many of these difficulties in detail. However, this paper has outlined a high-level approach for a focused and integrated application of Human Factors analyses for the specification and realisation of human subsystem safety requirements. [Pg.22]

The application software developer shall review the information in the specification to ensure that the requirements are unambiguous, consistent and understandable. Any deficiencies in the specified safety requirements shall be identified to the SIS subsystem developer. [Pg.76]

The second objective of the requirements of this clause is to review and evaluate the requirements placed on the software by the hardware and embedded software architecture of the SIS. These include side-effects of the SIS hardware/software behaviour, the application specific configuration of SIS hardware, the inherent fault tolerance of the SIS and the interaction of the SIS hardware and embedded software architecture with the application software for safety. [Pg.77]

The design of the application software architecture shall be based on the required SIS safety specification within the constraints of the system architecture of the SIS. It shall comply with the requirements of the selected subsystem design, its tool set and safety manual. [Pg.79]

Application software Software specific to the user application is application software such as logic sequences, permissive, calculations, and decisions necessary to meet the safety instrumented function requirements. [Pg.927]

Big Chemical Encyclopedia

Chemical substances, components, reactions, process design ...