Application software verification

The application software safety requirements specification will include  

Verification ensures that the specified requirements are being met at each phase of the application software development. 

No reproduction or networking permitted without license from IMS 

Data verification includes confirmation that data used within the application software is correct and where appropriate unique (for example that TAG names are uniquely assigned, that data is not misused by subsequent functions and that constants such as alarm set points are valid and correct). 

Verification for protection against unauthorised change, would include verification that the mechanisms exist (for example, password protection with levels of access) and that these mechanisms have been adequately utilised. 

1 The first objective of this clause is to demonstrate that the information is satisfactory. 

1 Verification planning shall be carried out for each phase of the application software life cycle in accordance with Clause 7. 

Copyright International Society of Automation Provided by IHS under license with ISA No reproduction or networking permitted without license fi 

NOTE 1 Data format in the application program should be verified for completeness self-consistency  

---

Install application software and perform IQ (set up, define, and document configuration settings, verify proper software installation through installation verification routines). 

Testing should include network transactions under normal and high loads. For this test, refer to verifications in the TCP/IP transfer protocol. The advantage here is that this is built into the system and will be performed on an ongoing basis. However, this is not 100% accurate, as there are rare situations where the test does not work. To be on the safe side, use routines (e.g., MD5 hash calculation routines based on 128-bit strings). Ask the vendor of your application software sometimes, such tests are built in. 

Maintenance records Application software documentation Data reproduction accuracy Documented verification of process steps Operator identification Data record review by quality control Electronic record/signature type, use, control, and audit trail... 

Installation Qualification (IQ) provides documented verification that instrumentation, computer hardware, operating system software, and application software have been purchased, received, and installed according to requirements and design. 

It is foimd that the hazard elements latent in the application software can be found and solved by V V, while the hazard elements latent in the system software can be solved by the design verification, V V, the reverse-compilation and the semi-dynamic simulation test. 

Application Software I/O Process Timing Designing Error - Verification (step3/4) - Validation... 

Notes 1 and 2 When limited variability languages such as lEC 61131-3 ladder diagram or function block diagram are used for the design, implementation, verification and validation of application software, then only two levels of the standard software V model shown in Figure 3 need apply. In this case, it is assumed that the used function blocks conform to lEC 61508-3,... 

Integration of the application software with the SIS subsystem is interpreted as the integration and verification of each process safety function implemented in the limited variability language. 

With regard to guidance on selection of application software test and verification methods and techniques, systems with a safety requirement up to SIL 3 should be verified in accordance with the guidance given in 12.7. For SIL 4 systems, the verifier should also confirm that the selected methods do oonform with the requirements of lEC 61508-3. 

Ideally, the interactions between the application code (SIF and non safety) and all variables (SIF and non safety) should be checked automatically by the application development software. If this feature is not available, the application software developer and other persons performing verification and validation of the application software should check all application code and associated variables for conformance to the separation rules given above. 

Full offline verification for hardware and application software should be completed prior to the installation of the change. 

At each distinct phase of the application software development cycle (including testing), verification confirms that the phase has been successfully completed. Verification is, in general, completed by a verification team that consists of one or more persons. 

Testing that the application software correctly satisfies its test specification is a verification activity. It is the combination of code review and structural testing that provides that the application software module satisfies its associated specification, i.e., it is verified. 

The continuing increase in analytical capabilities has allowed the use of highly sophisticated non-linear constitutive laws to model materials in conjunction with very finely detailed numerical models. This has enabled validating results to be derived from alternative software, thus enhancing confidence in the appropriateness and correctness of the results. However, as all analytical techniques have limits of applicability, an appropriate validation phase of methods and software verification should be carried out by means of either an independent analysis or a test. 

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). 

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... 

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... 

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... 

A suitable set of procedures for use of the tools should be identified, taking into account safety manual constraints, known weaknesses likely to introduce faults into the application software and any limitations on the coverage of earlier verification and validation. 

The software requirements of ANSI/ISA-84.00.01-2004-1 and ANSI/ISA-84.01-1996 are similar in many aspects, but there are some differences. The purpose of this discussion is to facilitate an understanding of these differences. This annex is also intended to introduce important concepts related to software-type and application software development and verification. 

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. 

For a tool of either category to be employed, there should be a precise definition of the tool s functionality. For a software development tool, the domain of applicability should be precisely known, and for a software verification tool, the analyses or checks it performs should be well defined. 

More than the half of the phases in our process are generic. Therefore, the techniques and tools used in these steps can be applied in various application domains. The domain-specific steps only differ in methods for the allocation of criticality levels to the system elements and the requirements for software verification validation. However, also common techniques and tools can be applied in these phases but have to be adapted to the domain-specific requirements respectively. There are only two process phases which are solely relevant to particular safety standards. For these steps domain-specific techniques and tools must be provided separately. 

Development and application of digital-based instrumentation and control systems, which have been back-fit to operating plants. This experience includes extensive computer software verification and validation. 

Functional safety management requires that a safety plan is produced to identify the required activities/strategy for SREC design, application software, integration, verification, and validation. 

---