Application software safety life-cycle requirements

APPLICATION SOFTWARE SAFETY LIFE CYCLE REQUIREMENTS (lEC 61511 CLAUSE 12) Requirements for application software summary... [Pg.158]

Each phase of the application software safety life cycle shall be defined in terms of its elementary activities, objectives, required input information and output results, verification requirements (see 12.7) and responsibilities (see Table 7 and Figure 11). [Pg.70]

NOTE 1 Provided that the application software safety life cycle satisfies the requirements of Table 7, it Is acceptable to tailor the depth, number and size of the phases of the V-model (see Figure 12) to take account of the safety integrity and the complexity of the project. [Pg.70]

If at any stage of the application software safety life cycle, a change is required pertaining to an earlier life-cycle phase, then that earlier safety life-cycle phase and the following phases shall be re-examined and, if changes are required, repeated and re-verified. [Pg.70]

The second objective of this clause is to demonstrate that the output results satisfy the defined requirements at each phase of the application software safety life cycle. [Pg.84]

Defined software safety life cycle - required activities defined to develop application software for each programmed SIS subsystem (sensor, logic solver, and final elements) -12.1.1.1... [Pg.71]

Basic objectives of application software safety requirements, as well as the relationship between SIS and application software safety life cycle, shall be discussed. Objectives have been enumerated in Table Vl/5.3.1-1 (see Table 7 of lEC 61511-1, courtesy of lEC). [Pg.456]

The criteria 1 to 8 may be reduced, especially those requiring full application of lEC 60880. Quality assurance shall divide the development and the modification phases of the software safety life cycle into specified activities. These activities shall include all what is necessary to achieve the required software quality, to verify that this quality is achieved, and to provide objective evidence to that effect. ... [Pg.65]

Integration tests shall be specified as early in the software safety life cycle as possible to ensure the compatibility of the application software with the hardware and embedded software platform such that the functional and performance safety requirements can be met. [Pg.83]

The full scope of software safety life cycle activities is beyond the scope of this book. However, we need to understand what is required of the project engineer and the designers involved in practical applications. So here are some key points seen fi om the position of the end user. [Pg.245]

A safety life cycle for the development of application software which satisfies the requirements of this clause shall be specified during safety planning and integrated with the SIS safety life cycle. [Pg.70]

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]

It specifies system architecture, hardware configuration, application software (user and integrator of SIS), and system integration, requirements for safety instmment functions (SIFs) including human factor, and safety life cycle. It also specifies the techniques and measures for SIL. [Pg.446]

So, one of the main objectives of lEC 61508 is to lay down requirements and procedures for the specification, design, development and validation of software to be used in safety related applications. The methods used are consistent with the other parts of the standard basically it sets out a software development life cycle model in parallel with the hardware development life cycle. [Pg.245]

The assessment and qualification of software for computer based systems important to safety requires (as e g. in lEC 60880) a set of detailed documents according to the development steps of the software life cycle. For pre-developed software the amount of documentation available and its detail will not be sufficient in most cases. On the other hand, the pre-developed software may have been operating in many applications, and it should be possible to evaluate this operating experience to demonstrate dependability. [Pg.51]

When a computer system is used in a safety-related application then this must be borne in mind at all stages in the software life cycle, i.e. specification, design, testing etc. and it is the particular influence of safety requirements on each of these stages which we shall be studying in this section. All systems consist of both hardware and software and factors relating to both... [Pg.246]

In this paper, a method of software safety verification at the system level based on STPA is proposed. We investigated the application of the STPA structure to software, and we found that STPA can be directly used for software. We mapped the results of the STPA safety analysis to a formal specification to be able to verify safety requirements at the software code level. The limitation of the method is that the formal specification is done manually which may lead to much effort to construct and check the potential combinations of relevant states. Therefore, we are exploring the automation of this step and integrate it with our A-STPA tool as future work. Furthermore, we plan in-depth case studies to improve the method by applying it to real safety-critical software in industry. We plan also to investigate the effectiveness of using the proposed method during an ISO 26262 life cycle in the automotive industry. [Pg.411]

These standards present a similar overall safety cycle and system life-cycle approach as in lEC 61508 with more in-depth details at each stage compared to lEC 61508. lEC 60964 covers the identification of the required safety function applicable to power plants, and lEC 61226 provides system categorization for different types of safety functions. The SIS design is then covered by lEC 60987 for hardware design and lEC 60880 for software design. IAEA 50-C-D now NS-R-1 covers the overall Safety Design, 50-SG-Dl gives the Classification of Safety Functions, 50-SG-D3 covers all Protection Systems, and 50-SG-D8 provides the requirements for the Instrumentation and Control Systems. [Pg.194]

Big Chemical Encyclopedia

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