GB/T 28808-2021 Railway applications—Communication, signaling and processing systems—Software for railway control and protection systems (English Version)
1 Scope
1.1 This document specifies the processes and technical requirements required for the development of software for programmable electronic systems used in rail traffic control and protection applications. It applies to any area where security is implied. These systems may be developed by using dedicated microprocessors, programmable logic controllers, distributed multiprocessor systems . Large-scale centralised processor systems or other architectures are used to implement them.
1.2 This document applies only to software and the interaction between the software and the system on which it resides.
1.3 This document is not relevant to software that has been identified as having no impact on safety, i.e. software failure does not affect any of the identified safety functions. The concept of SILO has been introduced due to the uncertainty in risk assessment and even hazard identification. For parts of the software where the safety impact is lower than the SIL1 function, at least the SILO requirements of this document must be met.
1.4 This document applies to all safety-related software used in rail control and protection systems, including:
a) Application design;
b) operating systems
c) support tools;
d) firmware.
Application programming includes high-level programming, low-level programming and specialised programming (e.g. ladder logic for programmable logic controllers).
1.5 This document also covers the use of existing software and tools. If such software is to be used, the specific requirements for pre-existing software in 7.3.4.7 and 6.5.4.16 and the requirements for tools in 6.7 are to be met.
1.6 Software developed according to any version of this document is considered to be compliant with this document and is not subject to the requirements for pre-existing software.
1.7 This document takes into account the current popularity of application design based on generic software for multiple applications which, when configured with data, algorithms or both, produces executable software for the application. Chapters 1 to 6 and 9 apply to both generic software and application data or algorithms. Chapter 8 applies only to application data or algorithms.
1.8 This document does not deal with commercial issues, which should be presented as an essential part of the contract. However, all provisions of this document need to be carefully considered in any commercial activity.
1.9 This document is not retrospective and should be applied primarily to new development, with full application to existing systems only when major modifications are made and for minor changes only 9.2. The assessor will need to analyse the evidence provided in the software documentation in order to confirm the adequacy of the determination of the scope and nature of the software changes. When upgrading or maintaining existing software, it is appropriate to apply this document.
2 Normative references
The content of the following documents constitute essential provisions of this document through the normative references in the text. Among them, the date of the reference document, only the date of the corresponding version applicable to this document; do not note the date of the reference document, its latest version (including all the revision of the list) applicable to this document.
3 Terms. Definitions and abbreviations
3.1 Terms and definitions
The following terms and definitions apply to this document.
4 Objectives, conformance and software security integrity levels
5 Software management and organisation
5.1 Organisation, roles and responsibilities
5.1.1 Objectives
To ensure that all personnel with responsibility for the software are organised, authorised and able to carry out their duties.
Note: Independence between roles may be required to reduce the likelihood that people in different roles will make the same misunderstanding or make the same mistake. This form of
This form of independence can be achieved by having different roles undertaken by different people, but it is not usually required that roles be located in different parts of the organisation or in different companies (unless specifically requested). It is also important that role holders who make judgements about the acceptability of a product or process from a safety perspective are not influenced by pressure from their colleagues or supervisors, or by commercial interests. This form of independence is more likely to require that different roles are located in different parts of the organisation or in different companies. In general, the higher the level of security, the greater the degree of independence required of the various roles and organisations.
6 Software Assurance
6.1 Software testing 6.1.1 Objectives
The objective of software testing is to determine the behaviour or performance of the software within the achievable limits of the selected test coverage according to the corresponding test specification, which is implemented by testers and/or integrators.
6.1.2 Input documentation
All required system, hardware and software documentation as specified in the software validation plan.
7 Generic software development
7.1 Generic software lifecycle and documentation
7.1.1 Objectives
To provide a description of the software itself, from high level abstraction to concrete refinement, in order to create a framework for the verification of the implemented security and for future maintenance activities.
7.1.2 Requirements
7.1.2.1 To achieve the required level of software security integrity, the documentation listed in Table A.1 of the Generic Software Output shall be required.
7.1.2.2 The sequence of deliverable documents described in Table A.1 reflects an ideal linear waterfall model. However, such a model is not meant to be used as a timeline for activities and as a benchmark for activity chains, as in practice it is often difficult to achieve strict adherence. Phases may overlap, but V&V activities should demonstrate consistency of inputs and outputs (documentation and software) within or between phases.
The purpose of the envisaged documentation is to provide a description of the software itself, from high level abstraction to concrete refinement, to create a framework to substantiate the security achieved and for future maintenance activities.
7.2 Software requirements
7.2.1 Objectives
7.2.1.1 To describe a set of software requirements to meet all software-related system requirements and security requirements, and to provide a set of easily understood documents for each subsequent phase.
7.2.1.2 Describe the overall software test specification.
8 Development of application data or algorithms
8.1 Objectives
8.1.1 Typical of many rail systems is the need to design each installation activity to meet the individual requirements of a particular application. Systems configured from application data and/or application algorithms allow the customisation of already approved generic software to the individual requirements of each specific application.
The objective of developing the application data is to obtain the correct data from a given installation activity and the examination of the expected behaviour, followed by an evaluation of the development process used for that application data.
The requirements for the development of the application algorithm are the same as those for the development of the generic software described in chapters 1 to 7 and 9.
As a typical example, the generic software of a system is pre-configured as a generic application for rail transport according to a certain set of application algorithms, and then instances of the application algorithms and interconnections and a set of configuration data are configured to each specific installation activity. For example, the signalling principles of an interlocking system (e.g. signalling machine management, turnout management) can be implemented by means of a set of application algorithms.
The application data is usually expressed in the form of parameter values or external object descriptions (identifiers, types, locations, etc.). Application algorithms may take the form of, for example, function block diagrams, state diagrams and ladder diagrams (which determine the expected response of the system based on its inputs, current state and specific parameter values). Application algorithms include the logical connections and operations to be performed.
Application data/algorithms are usually generated using special tools and can be represented in tables or diagrams, often after being converted into source code (with syntax and semantics) processed by a special language, which can be interpreted or compiled into executable code.
Customisation of the system through configurability allows the designer to have varying degrees of control over software functionality.
8.1.2 The protocols and tools used for development should be appropriate to the level of system security integrity determined by the function being developed.
8.1.3 The requirements for the initial development of a configurable system and the subsequent development of data/algorithms specific to each set of applications are described in 8.4.
8.2 Input documentation
9 Software deployment and maintenance
9.1 Software deployment
9.1.1 Objectives
To ensure that the software deployed in the final application environment performs as required and maintains the required level of security integrity and trustworthiness.
9.1.2 Input documentation
All design, development and analysis documentation associated with the deployment.
Appendix A (prescriptive) Guidelines for the selection of techniques and measures
Appendix B (informative) Objectives and description of technologies
Appendix C (prescriptive) Responsibilities and key capabilities of software roles
Appendix D (informative) Summary of documentation controls
Bibliography
1 Scope
2 Normative references
3 Terms. Definitions and abbreviations
4 Objectives, conformance and software security integrity levels
5 Software management and organisation
7 Generic software development
8.1 Objectives
9 Software deployment and maintenance
Appendix A (prescriptive) Guidelines for the selection of techniques and measures
Appendix B (informative) Objectives and description of technologies
Appendix C (prescriptive) Responsibilities and key capabilities of software roles
Appendix D (informative) Summary of documentation controls
Bibliography
GB/T 28808-2021 Railway applications—Communication, signaling and processing systems—Software for railway control and protection systems (English Version)
Standard No.
GB/T 28808-2021
Status
valid
Language
English
File Format
PDF
Word Count
46500 words
Price(USD)
1395.0
Implemented on
2022-7-1
Delivery
via email in 1~5 business day
Detail of GB/T 28808-2021
Standard No.
GB/T 28808-2021
English Name
Railway applications—Communication, signaling and processing systems—Software for railway control and protection systems
1 Scope
1.1 This document specifies the processes and technical requirements required for the development of software for programmable electronic systems used in rail traffic control and protection applications. It applies to any area where security is implied. These systems may be developed by using dedicated microprocessors, programmable logic controllers, distributed multiprocessor systems . Large-scale centralised processor systems or other architectures are used to implement them.
1.2 This document applies only to software and the interaction between the software and the system on which it resides.
1.3 This document is not relevant to software that has been identified as having no impact on safety, i.e. software failure does not affect any of the identified safety functions. The concept of SILO has been introduced due to the uncertainty in risk assessment and even hazard identification. For parts of the software where the safety impact is lower than the SIL1 function, at least the SILO requirements of this document must be met.
1.4 This document applies to all safety-related software used in rail control and protection systems, including:
a) Application design;
b) operating systems
c) support tools;
d) firmware.
Application programming includes high-level programming, low-level programming and specialised programming (e.g. ladder logic for programmable logic controllers).
1.5 This document also covers the use of existing software and tools. If such software is to be used, the specific requirements for pre-existing software in 7.3.4.7 and 6.5.4.16 and the requirements for tools in 6.7 are to be met.
1.6 Software developed according to any version of this document is considered to be compliant with this document and is not subject to the requirements for pre-existing software.
1.7 This document takes into account the current popularity of application design based on generic software for multiple applications which, when configured with data, algorithms or both, produces executable software for the application. Chapters 1 to 6 and 9 apply to both generic software and application data or algorithms. Chapter 8 applies only to application data or algorithms.
1.8 This document does not deal with commercial issues, which should be presented as an essential part of the contract. However, all provisions of this document need to be carefully considered in any commercial activity.
1.9 This document is not retrospective and should be applied primarily to new development, with full application to existing systems only when major modifications are made and for minor changes only 9.2. The assessor will need to analyse the evidence provided in the software documentation in order to confirm the adequacy of the determination of the scope and nature of the software changes. When upgrading or maintaining existing software, it is appropriate to apply this document.
2 Normative references
The content of the following documents constitute essential provisions of this document through the normative references in the text. Among them, the date of the reference document, only the date of the corresponding version applicable to this document; do not note the date of the reference document, its latest version (including all the revision of the list) applicable to this document.
3 Terms. Definitions and abbreviations
3.1 Terms and definitions
The following terms and definitions apply to this document.
4 Objectives, conformance and software security integrity levels
5 Software management and organisation
5.1 Organisation, roles and responsibilities
5.1.1 Objectives
To ensure that all personnel with responsibility for the software are organised, authorised and able to carry out their duties.
Note: Independence between roles may be required to reduce the likelihood that people in different roles will make the same misunderstanding or make the same mistake. This form of
This form of independence can be achieved by having different roles undertaken by different people, but it is not usually required that roles be located in different parts of the organisation or in different companies (unless specifically requested). It is also important that role holders who make judgements about the acceptability of a product or process from a safety perspective are not influenced by pressure from their colleagues or supervisors, or by commercial interests. This form of independence is more likely to require that different roles are located in different parts of the organisation or in different companies. In general, the higher the level of security, the greater the degree of independence required of the various roles and organisations.
6 Software Assurance
6.1 Software testing 6.1.1 Objectives
The objective of software testing is to determine the behaviour or performance of the software within the achievable limits of the selected test coverage according to the corresponding test specification, which is implemented by testers and/or integrators.
6.1.2 Input documentation
All required system, hardware and software documentation as specified in the software validation plan.
7 Generic software development
7.1 Generic software lifecycle and documentation
7.1.1 Objectives
To provide a description of the software itself, from high level abstraction to concrete refinement, in order to create a framework for the verification of the implemented security and for future maintenance activities.
7.1.2 Requirements
7.1.2.1 To achieve the required level of software security integrity, the documentation listed in Table A.1 of the Generic Software Output shall be required.
7.1.2.2 The sequence of deliverable documents described in Table A.1 reflects an ideal linear waterfall model. However, such a model is not meant to be used as a timeline for activities and as a benchmark for activity chains, as in practice it is often difficult to achieve strict adherence. Phases may overlap, but V&V activities should demonstrate consistency of inputs and outputs (documentation and software) within or between phases.
The purpose of the envisaged documentation is to provide a description of the software itself, from high level abstraction to concrete refinement, to create a framework to substantiate the security achieved and for future maintenance activities.
7.2 Software requirements
7.2.1 Objectives
7.2.1.1 To describe a set of software requirements to meet all software-related system requirements and security requirements, and to provide a set of easily understood documents for each subsequent phase.
7.2.1.2 Describe the overall software test specification.
8 Development of application data or algorithms
8.1 Objectives
8.1.1 Typical of many rail systems is the need to design each installation activity to meet the individual requirements of a particular application. Systems configured from application data and/or application algorithms allow the customisation of already approved generic software to the individual requirements of each specific application.
The objective of developing the application data is to obtain the correct data from a given installation activity and the examination of the expected behaviour, followed by an evaluation of the development process used for that application data.
The requirements for the development of the application algorithm are the same as those for the development of the generic software described in chapters 1 to 7 and 9.
As a typical example, the generic software of a system is pre-configured as a generic application for rail transport according to a certain set of application algorithms, and then instances of the application algorithms and interconnections and a set of configuration data are configured to each specific installation activity. For example, the signalling principles of an interlocking system (e.g. signalling machine management, turnout management) can be implemented by means of a set of application algorithms.
The application data is usually expressed in the form of parameter values or external object descriptions (identifiers, types, locations, etc.). Application algorithms may take the form of, for example, function block diagrams, state diagrams and ladder diagrams (which determine the expected response of the system based on its inputs, current state and specific parameter values). Application algorithms include the logical connections and operations to be performed.
Application data/algorithms are usually generated using special tools and can be represented in tables or diagrams, often after being converted into source code (with syntax and semantics) processed by a special language, which can be interpreted or compiled into executable code.
Customisation of the system through configurability allows the designer to have varying degrees of control over software functionality.
8.1.2 The protocols and tools used for development should be appropriate to the level of system security integrity determined by the function being developed.
8.1.3 The requirements for the initial development of a configurable system and the subsequent development of data/algorithms specific to each set of applications are described in 8.4.
8.2 Input documentation
9 Software deployment and maintenance
9.1 Software deployment
9.1.1 Objectives
To ensure that the software deployed in the final application environment performs as required and maintains the required level of security integrity and trustworthiness.
9.1.2 Input documentation
All design, development and analysis documentation associated with the deployment.
Appendix A (prescriptive) Guidelines for the selection of techniques and measures
Appendix B (informative) Objectives and description of technologies
Appendix C (prescriptive) Responsibilities and key capabilities of software roles
Appendix D (informative) Summary of documentation controls
Bibliography
Contents of GB/T 28808-2021
1 Scope
2 Normative references
3 Terms. Definitions and abbreviations
4 Objectives, conformance and software security integrity levels
5 Software management and organisation
7 Generic software development
8.1 Objectives
9 Software deployment and maintenance
Appendix A (prescriptive) Guidelines for the selection of techniques and measures
Appendix B (informative) Objectives and description of technologies
Appendix C (prescriptive) Responsibilities and key capabilities of software roles
Appendix D (informative) Summary of documentation controls
Bibliography
