BS IEC 60880-2-2000 pdf free download – Nuclear power plants — Instrumentation and control systems important to safety — Software aspects for computer-based systems performing category A functions
Operational system software may be used in different projects.
Many system designs make extensive use of configuration data.Configuration data may beassociated with operational system software or with application software. Configuration dataassociated with application software consists mainly of plant engineering data resulting fromthe design of the plant, and is often prepared by plant designers who are not required to havesoftware skills.
Configuration data can be divided into:
– data items which are not intended to be modified on-line by plant operators,and which are
submitted to the same requirements as apply to the rest of the software;
parameters, i.e.data items which may be modified by operators during plant operation (forexample，alarm limits，set points，data required to calibrate instrumentation) and whichneed specific requirements.
Many modern l&C equipment platforms are provided with extensive development tools whichenable system engineers to design and produce executable codes.
As an example,a typical l&C system, developed using components of an equipment family,includes the following:
pre-developed software components, such as the operational system software kernel andthe application function libraries.Generally, these components have been developed usinggeneral-purpose languages;
configuration data needed to adapt the operational system software kernel to the l/oenvironment and to the services required by the application;
application software developed using an application-oriented language.
5.3Software development approach
Software usually contributes strongly to the functions performed by the l&C system. It mayalso support additional functions introduced by system design (e.g. initialisation andsurveillance of hardware, communication between,and synchronisation of，subsystems).Thus, the software safety lifecycle is in most cases strongly integrated with the system safetylifecycle. In particular，the software requirements specification is a part of，or is deriveddirectly from, system specification and system design.”
Though the verification of new software components is definitely a part of the software safetylifecycle, there is often no separate and well-identified boundary between software integrationand system integration.Therefore, in this standard, software integration is considered to be apart of system integration.Software validation too is not a purely software activity: in thisstandard, it is considered a part of system integration and/or system validation.
The standard assumes that the software life cycle, originally intended for the development ofsoftware with general-purpose languages, is also applicable to application-oriented languagesand configuration of pre-developed software.
However, it recognises differences in the development process by introducing dedicated sub-processes for each software type at the implementation level:
– implementation using general-purpose languages;
– implementation using application-oriented languages with associated code generators;
– selection, use and configuration of pre-developed software products.
As boxes “Application software development/generation” and “Development of new operational system software” in Figure 2 represent a large and essential part of the software safety lifecycle, a “zoom” is provided in Figure 3, which illustrates in more detail the activities between software requirements specification and validation, with a clear representation of the three different implementation paths. In that figure, references to related subclauses of this standard are in brackets.
The standard also gives additional requirements for software in Annex B.BS IEC 60880-2 pdf download.