GB/T 28808-2021Railway applications - Communication, signaling and processing systems - Software for railway control and protection systems (English PDF)

foreword

This document is in accordance with the provisions of GB/T 1:1-2020 "Guidelines for Standardization Work Part 1: Structure and Drafting Rules of Standardization Documents"

drafted:

This document replaces GB/T 28808-2012 "Rail traffic communication, signal and processing system control and protection system software", and

Compared with GB/T 28808-2012, in addition to structural adjustment and editorial changes, the main technical changes are as follows:

a) Deleted the following terms and definitions: 3:3 Usability, 3:5 Design Agency, 3:7 Elements, 3:11 Error Avoidance, 3:16 Product, 3:18 Reliable

3:19 Requirements Traceability Objectives (see Chapter 3 of the:2012 edition);

b) Added the following terms and definitions: 3:1:4 Component, 3:1:5 Configuration Administrator, 3:1:6 Client, 3:1:8 Entity, 3:1:16 Integration,

3:1:17 Integrator, 3:1:18 Existing software, 3:1:19 Open source software, 3:1:21 Project management, 3:1:22 Project manager, 3:1:23

Reliability, 3:1:24 Robustness, 3:1:25 Requirements Manager, 3:1:26 Requirements Management, 3:1:30 Security Functions, 3:1:33 Software Baselines,

3:1:34 Software Deployment, 3:1:41 Testers, 3:1:42 Testing, 3:1:43T1 Tools, 3:1:44T2 Tools, 3:1:45T3

class tools (see 3:1);

c) Changed the independence requirements of software management and organization (see Chapter 5, Chapter 5, Chapter 6, Chapter 7 of the:2012 edition);

d) Added requirements for software deployment and software maintenance (see 5:1);

e) the definition of roles involved in software development and the requirements for individual competencies have been added (see 5:2);

f) new clauses on tools were added (see 6:7);

g) Added overall software testing and corresponding requirements (see 7:7);

h) Changed the requirements for software development outputs (see Appendix A, Appendix A of the:2012 edition);

i) Added Appendix C to further clarify the key capabilities of the software roles and their responsibilities (see Appendix C):

This document uses the redrafted law to modify and adopt IEC 62279:2015 "Control and Protection of Rail Transit Communication, Signaling and Processing Systems"

system software":

Compared with IEC 62279:2015, this document has made the following structural adjustments:

---3:1:9 corresponds to 3:1:10 of IEC 62279:2015;

---3:1:10 corresponds to 3:1:11 of IEC 62279:2015;

---3:1:11 corresponds to 3:1:9 of IEC 62279:2015;

---Appendix B corresponds to Appendix D of IEC 62279:2015, and adds the chapter number of each target and description;

---Appendix C corresponds to Appendix B of IEC 62279:2015;

---Appendix D corresponds to Appendix C of IEC 62279:2015:

The technical differences between this document and IEC 62279:2015 and their reasons are as follows:

--- Regarding normative reference documents, this document has made adjustments with technical differences to adapt to the technical conditions of our country and the circumstances of the adjustment:

The situation is reflected in Chapter 2 "Normative References", and the specific adjustments are as follows:

* Replace ISO 9000:2015 with GB/T 19000 which is equivalent to adopting international standards (see 6:5:4:2);

* Replace ISO 9001:2008 with GB/T 19001 which is equivalent to adopting international standards (see 5:1:2:1, 5:2:2:3, 6:4:1:2,

Table A:9 and Table C:11);

* Replace ISO /IEC 25010 (see 9:2:4:4, Table C:11) with GB/T 25000:10, which has been modified to adopt international standards:

The following editorial changes have been made to this document:

--- Deleted IEC 62278:2002 in the list of normative references in Chapter 2;

--- Added description to indicate Appendix D (see 5:3:2:14);

--- Added abbreviations "API" "CFG" "DSL" and "LCF";

--- Changed references;

--- Changed the error in IEC 62279:2015:

* In 6:6:3, replace "(see 9:2:4:11)" with "(see 9:2:4:10)";

* In Table A:1, the symbol "See Note 2" was originally marked in Documents No: 29, 30, and 31, and was changed to be marked in Documents No: 30, 31, and 32;

* "Software Analysis Technology (6:3)" in Table A:8 is changed to "Software Analysis Technology (6:2)";

* In Table A:9, "7:1" in the reference entry is changed to "6:5";

* In Table A:12, the second serial number 9 and serial number 10 are changed to serial number 10 and serial number 11:

Please note that some content of this document may be patented: The issuing agency of this document assumes no responsibility for identifying patents:

Introduction

This document is used in conjunction with GB/T 21562 and GB/T 28809:

GB/T 21562-2008 is applicable to a wide range of rail transit systems, while GB/T 28809 is applicable to the entire rail transit control and prevention

Approval process for individual systems that may exist in the system: This document focuses on the use of software to provide software that meets safety integrity requirements:

method, the safety integrity is given to the software through a more comprehensive consideration:

This document provides a set of requirements for the development, deployment and maintenance of any safety-related components used in rail traffic control and protection applications:

All software should comply with these requirements: This document specifies relevant organizational structures, relationships between organizations, and development, deployment, and maintenance activities:

This document also provides guidelines for personnel qualifications and expertise:

The key concept of this document is the Software Safety Integrity Level (SIL): This document identifies five software safety integrity levels: SIL0~

SIL4, of which SIL0 is the lowest level and SIL4 is the highest level: The higher the risk of software failure, the higher the software safety integrity level:

higher:

This document clarifies the technologies and measures for five software safety integrity levels, and the technologies and measures required for SIL0~SIL4 are in Appendix A

listed in the normative table: The technical requirements required for SIL1 and SIL2 in this document are the same, and the technical requirements required for SIL3 and SIL4 are similar

same: This document does not give guidance on which software safety integrity level is appropriate for a given risk: because the decision

The policy depends on a number of factors, including the nature of the application, the extent of the security functions undertaken by other systems, and social and economic factors:

The process of assigning safety functions to software is defined by GB/T 21562 and GB/T 28809:

This document specifies the necessary measures to meet these requirements:

GB/T 21562 and GB/T 28809 require a systematic approach to:

a) identify hazards, assess risks and make decisions based on risk criteria;

b) determine the necessary risk reduction measures to meet the risk acceptance criteria;

c) define a comprehensive system security requirements specification for the necessary security safeguards to achieve the required risk reduction;

d) select an appropriate system architecture;

e) the technical and managerial activities necessary for planning, monitoring and control that translate the safety requirements specification into

A safety-related system whose safety integrity is confirmed:

When decomposing the specification into a design consisting of safety-related systems and components, the safety integrity level needs to be further considered:

Step allocation, and finally form the required software safety integrity level:

At the current state of the art, whether it is the application of quality assurance measures (so-called fault avoidance measures and fault detection measures) or

The application of software fault tolerance method cannot guarantee the absolute safety of software: There is no way to prove a relatively complex security-related software

There are no defects, especially lack of specification and design defects:

Principles applied to the development of high-integrity software, including but not limited to:

a) a top-down design approach;

b) modular;

c) verification of each stage of the development life cycle;

d) proven components and component libraries;

e) clear documentation and traceability;

f) auditable documentation;

g) confirm;

h) evaluation;

i) configuration management and change control;

j) Consequential considerations in organizational and individual capabilities:

The system safety requirements specification identifies all safety functions assigned to the software and determines the safety integrity of these safety functions

Sex grade: Figure 1 presents a series of practical steps in applying this document and is described below:

a) Define the software requirements specification, taking into account the software architecture; the software architecture is the specification of the security for the software and the software safety integrity level

In place of the full strategy, see 7:2 and 7:3;

b) design, develop and test software according to the software quality assurance plan, software safety integrity level and software life cycle, see 7:4

and 7:5;

c) software integration and software-hardware integration on target hardware, and functional verification, see 7:6;

d) accept and deploy software, see 7:7 and 9:1;

e) During the operation phase of the software life cycle, if the software needs maintenance, if applicable, restart this document for processing, see 9:2:

Many activities intersect with software development, these activities include: testing (see 6:1), verification (see 6:2), validation (see 6:3), evaluation (see 6:3)

6:4), quality assurance (see 6:5), and modification and change control (see 6:6):

This document also makes requirements for supporting tools (see 6:7) and systems configured by application data or algorithms (see clause 8):

This document also makes requirements for the independence and personal competence of the roles involved in the software development process (see 5:1, 5:2 and Appendix C):

This document does not mandate the use of a specific software development life cycle, exemplary life cycles are given in 5:3, Figure 3, Figure 4 and 7:1

and documentation set:

The formatted table lists the various techniques/measures for the Software Safety Integrity Level that meet the requirements of Annex A: cross-reference with this table

The technical vocabulary given in Appendix B is used, which briefly describes the objectives and content of each technology/measure:

Figure 1 Example of a software roadmap

Rail transit communication, signalling and processing systems

Control and Protection System Software

1 Scope

1:1 This document specifies the process and technical requirements required for the development of software for programmable electronic systems used in rail traffic control and protection applications:

beg: It applies to any field with implicit security: These systems may be implemented through the use of dedicated microprocessors, programmable logic controllers,

distributed multiprocessor systems, large-scale centralized processor systems, or other architectures:

1:2 This document applies only to the software and the interaction between the software and the system in which the software is installed:

1:3 This document has nothing to do with software that has been identified as having no impact on safety, i:e: software failure will not affect any identified safety features:

can: Due to the uncertainty in risk assessment and even hazard identification, the concept of SIL0 is introduced: For safety impact less than

The software part of the SIL1 function shall at least meet the requirements of SIL0 of this document:

1:4 This document applies to all safety-related software used in rail traffic control and protection systems, including:

a) application design;

b) operating system;

c) support tools;

d) Firmware:

Application programming includes high-level programming, low-level programming and special programming (such as: programmable logic controller ladder

logic):

1:5 This document also addresses the use of existing software and tools: If you want to use this type of software, you must meet the requirements in 7:3:4:7 and 6:5:4:16

Specific requirements for existing software, and requirements for tools in 6:7:

1:6 Software developed according to any version of this document is deemed to comply with the provisions of this document and is not subject to the requirements for existing software:

1:7 This document considers the current situation of application design based on general-purpose software suitable for a variety of applications:

The software generates executable software for the application after it is configured through data, algorithms, or both: Chapters 1 to 6 and 9 apply to both

Generic software is also suitable for applying data or algorithms: Chapter 7 applies only to general-purpose software, and Chapter 8 applies only to application data or algorithms:

1:8 This document does not deal with commercial issues, which should be raised as an essential part of the contract: But in any business activity, careful consideration is required:

Consider all the terms of this document:

1:9 This document is not retrospective and is mainly used for new development: For existing systems, a comprehensive application is only performed when major modifications are made:

For small changes, only 9:2 needs to be applied: Evaluators need to analyze the evidence provided in the software documentation in order to confirm changes to the software

Whether the determination of the scope and nature is sufficient: This document should be applied when upgrading or maintaining existing software:

2 Normative references

The contents of the following documents constitute essential provisions of this document through normative references in the text: Among them, dated citations

documents, only the version corresponding to that date applies to this document; for undated references, the latest edition (including all amendments) applies to

this document:

GB/T 19000 Quality Management System Fundamentals and Terminology (GB/T 19000-2016, ISO 9000:2015, IDT)

GB/T 19001 Quality Management System Requirements (GB/T 19001-2016, ISO 9001:2015, IDT)

GB/T 25000:10 System and Software Engineering System and Software Quality Requirements and Evaluation (SQuaRE) Part 10: Systems and Software

Software Quality Model (GB/T 25000:10-2016, ISO /IEC 25010:2011, MOD)