Path: Home > GB/T > Page116 > GB/T 28808-2021

Price & Delivery

US$1959.00 · In stock · Download in 9 seconds
GB/T 28808-2021: Railway applications - Communication, signaling and processing systems - Software for railway control and protection systems
Delivery: 9 seconds. True-PDF full-copy in English & invoice will be downloaded + auto-delivered via email. See step-by-step procedure
Status: Valid

Std ID	Version	USD	Buy	Deliver [PDF] in	Title (Description)
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
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

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