|
US$1959.00 · In stock
Delivery: <= 10 days. True-PDF full-copy in English will be manually translated and delivered via email.
GB/T 28808-2021: Railway applications - Communication, signaling and processing systems - Software for railway control and protection systems
Status: Valid GB/T 28808: Evolution and historical versions
| Standard ID | Contents [version] | USD | STEP2 | [PDF] delivered in | Standard Title (Description) | Status | PDF |
| GB/T 28808-2021 | English | 1959 |
Add to Cart
|
10 days [Need to translate]
|
Railway applications - Communication, signaling and processing systems - Software for railway control and protection systems
| Valid |
GB/T 28808-2021
|
| GB/T 28808-2012 | English | RFQ |
ASK
|
10 days [Need to translate]
|
Railway applications -- Communication, signaling and processing systems -- Software for railway control and protection systems
| Obsolete |
GB/T 28808-2012
|
PDF similar to GB/T 28808-2021
Basic data | Standard ID | GB/T 28808-2021 (GB/T28808-2021) | | Description (Translated English) | Railway applications - Communication, signaling and processing systems - Software for railway control and protection systems | | Sector / Industry | National Standard (Recommended) | | Classification of Chinese Standard | S04 | | Word Count Estimation | 103,153 | | Issuing agency(ies) | State Administration for Market Regulation, China National Standardization Administration | GB/T 28808-2021: Railway applications - Communication, signaling and processing systems - Software for railway control and protection systems
---This is a DRAFT version for illustration, not a final translation. Full copy of true-PDF in English version (including equations, symbols, images, flow-chart, tables, and figures etc.) will be manually/carefully translated upon your order.
Railway applications -- Communication, signaling and processing systems -- Software for railway control and protection systems
ICS 45:060
CCSS04
National Standards of People's Republic of China
Replaces GB/T 28808-2012
Rail transit communication, signalling and processing systems
Control and Protection System Software
(IEC 62279:2015, MOD)
Published on 2021-12-31
2022-07-01 Implementation
State Administration for Market Regulation
Released by the National Standardization Administration
directory
Preface III
Introduction V
1 Scope 1
2 Normative references 1
3 Terms, Definitions and Abbreviations 2
3:1 Terms and Definitions 2
3:2 Abbreviations 6
4 Objectives, conformance and software safety integrity level 7
5 Software Management and Organization 8
5:1 Organization, roles and responsibilities 8
5:2 Human Capability 11
5:3 Lifecycle and Documentation 11
6 Software Assurance 14
6:1 Software Testing 14
6:2 Software Verification 15
6:3 Software Confirmation 16
6:4 Software Evaluation 18
6:5 Software Quality Assurance 19
6:6 Modification and Change Control 21
6:7 Support Tools and Languages 22
7 General Software Development 25
7:1 Generic Software Lifecycle and Documentation 25
7:2 Software Requirements 25
7:3 Architecture and Design 27
7:4 Component Design 31
7:5 Component Implementation and Testing 33
7:6 Integration 34
7:7 Overall Software Testing/Final Validation 35
8 Development of application data or algorithms37
8:1 Objective 37
8:2 Input documents 37
8:3 Exporting documents 37
8:4 Requirements 37
9 Software Deployment and Maintenance 41
9:1 Software Deployment 41
9:2 Software Maintenance 42
Appendix A (normative) Criteria for the selection of technologies and measures 45
APPENDIX B (INFORMATIVE) OBJECTIVES AND DESCRIPTION OF THE TECHNOLOGY 56
Appendix C (Normative) Software Role Responsibilities and Key Capabilities 87
Appendix D (Informative) Document Control Summary 93
Reference 95
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:
This document is proposed by the National Railway Administration:
This document is under the jurisdiction of the National Standardization Technical Committee for Traction Electrical Equipment and Systems (SAC/TC278):
This document is drafted by: CRRC Zhuzhou Electric Locomotive Research Institute Co:, Ltd:, Tongji University, China Railway Research Institute Group Co:, Ltd:
Department of Standards and Metrology, Beijing Quanlu Communication Signal Research and Design Institute Group Co:, Ltd:, China Railway Research Institute Group Co:, Ltd:
Xin Signal Research Institute, Beijing Hollysys System Engineering Co:, Ltd:
The main drafters of this document: Zhou Zhifei, Liu Buqi, Xu Zhongwei, Zhao Tianshi, Qiu Zhaoyang, Zhang Ping, Wang Xiaoliang, Li Wenbo:
The previous versions of this document and its superseded documents are as follows:
---First published in:2012 as GB/T 28808-2012;
---This is the first revision:
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)
Tips & Frequently Asked Questions:Question 1: How long will the true-PDF of GB/T 28808-2021_English be delivered?Answer: Upon your order, we will start to translate GB/T 28808-2021_English as soon as possible, and keep you informed of the progress. The lead time is typically 6 ~ 10 working days. The lengthier the document the longer the lead time. Question 2: Can I share the purchased PDF of GB/T 28808-2021_English with my colleagues?Answer: Yes. The purchased PDF of GB/T 28808-2021_English will be deemed to be sold to your employer/organization who actually pays for it, including your colleagues and your employer's intranet. Question 3: Does the price include tax/VAT?Answer: Yes. Our tax invoice, downloaded/delivered in 9 seconds, includes all tax/VAT and complies with 100+ countries' tax regulations (tax exempted in 100+ countries) -- See Avoidance of Double Taxation Agreements (DTAs): List of DTAs signed between Singapore and 100+ countriesQuestion 4: Do you accept my currency other than USD?Answer: Yes. If you need your currency to be printed on the invoice, please write an email to [email protected]. In 2 working-hours, we will create a special link for you to pay in any currencies. Otherwise, follow the normal steps: Add to Cart -- Checkout -- Select your currency to pay. Question 5: Should I purchase the latest version GB/T 28808-2021?Answer: Yes. Unless special scenarios such as technical constraints or academic study, you should always prioritize to purchase the latest version GB/T 28808-2021 even if the enforcement date is in future. Complying with the latest version means that, by default, it also complies with all the earlier versions, technically.
|