GB/T 28808-2012
基本信息
标准号： GB/T 28808-2012
中文名称：轨道交通 通信、信号和处理系统 控制和防护系统软件
标准类别：国家标准(GB)
标准状态：现行
出版语种：简体中文
下载格式：.rar .pdf
下载大小：10031KB
标准分类号
关联标准
出版信息
相关单位信息
标准简介
GB/T 28808-2012 轨道交通 通信、信号和处理系统 控制和防护系统软件
GB/T28808-2012
标准压缩包解压密码：www.bzxz.net
标准图片预览
标准内容
ICS45.060
中华人民共和国国家标准
GB/T 28808—2012/IEC 62279.2002轨道交通
通信、信号和处理系统
控制和防护系统软件
Railway applications--Communication ,signaling and processing systcms-Software for railway control and protection systems(IEC 62279;2002,1DT)
2012-11-05发布
中华人民共和国国家质量监督检验检疫总局中国国家标准化管理委员会
2013-02-01实施
规范性引用文件
术语和定义
日标和一致性
软件安全完整性等级
5.2要求
6人员和职责
6.1目标．
5.2要求
7生命周期和文挡
7.1目标
7.2要求
8软件需求规范
8.2输人文档
8.3输出文档
8.4要求··
9软件结构
9.1目标.
9.2输入文档
输出文档，
要求·
10软件设计和实现
输人文档
输出文档
11软件验证和测试
输人文档
输出文档
GB/T 28808--2012/IEC 62279:2002T
GB/1 28808—2012/JEC 62279:200212软件/硬件集成
12.2输人文档
12.3输出文档
12.4要求
18软件确认
13.1目标
13.2输人文档
13.3输出文档
13.4要求
14软件评估
14.2输人文档
14.3输出文档
15软件质量保证
15.2输人文档
输出文档
16软作维护
16.2输人文档
16.3输出文档
15.4要求
17基于应用数据配置的系统
17.2输人文档
17.3输出文档
17.4要求
附录A（规范性附录）技术和措施的选择推则录B（资料性附录）技术参考资料附录NA（资料性附录）与规范性引用国际文件有关的我国文件16
本标推按照G日/T1.1一2009给出的规则起草，GB/T28808—2012/IEC62279:2002本标准采用翻译法等同采用IEC62279:2002轨道交通通信、信号和处理系统控制和防护系统软件。
与本标雄中规范性引用文件有一致性对应关系的我国文件见附录NA。本标准做了下列编辑性修改：
—将第3章中引用的IEC60050-191.ISO/IEC2382、1S0/EC9126、IEEE6J0.12文件补充到第2章规范性引用文件中；
修改了1FC62279：2002中第2章的脚注1，因为[EC62278已发布：脚注1改为对IS09000ISO9000-3.IS()9001提存在新版文件—采用等同来用IEC62425：2007的GB/T28809—2012代替EVV50129；一修订正文中引用的ISO9000、ISO9000-3、ISO9001的版本号，与第2章产明的版本号一致，—IEC62279：2002的一级子列项编号采用的是i）、i），或1）,2）、\本标准中统一修改为字母编号形式:a)、h)、1
—一附录B中，对每章内的单列一行的黑体字符“目标”、“描述\和“参考文献”进行编号，以符合中文习惯。免费标准下载网bzxz
本标准由中华人民共和国铁道部提出。本标准由全国牵引电气设备与系统标准化技术委员会（SAC/TC278)归口。本标准主要起草单位：同济大学，铁道部标推计量研究所。本标准参加起草单位：株洲南车时代电气股份有限公司、北京全路通信信号研究设计院。本标准主要起草人:徐中伟、赵天时、王奇。本标雅参加起草人：范椎成、孙超、严云升、陈邦兴、黄银霞、呼爱蝉、牛道恒。GB/T28808—2012/IEC62279:2002引言
本标准与GB/T21562（IEC62278）和GB/T28809—2012（IEC62425：2007,IDT)配套使用。GB/T21562（IEC62278）适用于大范围的系统尚题.而GB/T28809-2012（1E062425：2007，JDT)道用于整个轨道交通控制和防护系统中某单个系统的批准试程。为提供满足安全完整性要求的软件，本标准关注于通过更全面考虑后提出软件安全完整性要求所要采用的方法。本标准从IEC/TC 65第九工作组（WG9)早期T.作中得到很多指导。同时，对铁路信号工程师协会（IRSE）的工作也加以了考虑，特别是关注相同主题的1尽技术报告。本标准的关键思想是其对软件安全完性等级的考。软件失效的后果越严重，软件安全完整性等级也就越高。
标准确定了从最低0级到最高4级的5个软件安全完整性等级的技术和措施。其中1级～4级指的是安全相关软件,0级指的是非安全相关软件。将○级包括进本标准是为了让非安全相关系统软件开发向安全相关系统软件开发实现顺利过渡。附表给出了各个软件安全完整性等缀和非安全相关等级要求的技术和措施。在本版本中，1级和2级的技术要求相同,3级和4级的要求相同。本标准没有给出某一风险应适用于哪个软件安全完整性等级的具体指导意见。这一结论需要考虑诸多浆，包括应用的特性、其他系统承担的安全功能范围以及社会和经济因素。软件安全功能的分配由GB/T21562（IEC62278）和GB/T28809--2012（JEC62425：2007，IDT)规定。
本标准规定了满足这些需求的必要措施。该过见图1。GB/T21562(IEC62278)和GB/T28809—2012(IEC62425:2007.IDT)需采用系统性的方法，以：a）确定危害、风险和风险准则：b）为满足风险准则，确定必要的风险降低（措施）；c）为实现所需的风险降低，为必要的安全防护措施定义一个全面的系统安全需求规范：d）选择一个合适的系统结构：
规划、监督和控制那些把系统安全诺求规范变成安全性能（或安全完整性）已确认的安全相关e
系统。
在将该规范分解到由安全相关系统和组件组成的设计当中时.对安全完整性等级的进一步分配就完成了，并最终形所带的软件安全完整性等级。目前，无论是质域保证法（即避错措施)还是软件容错法的应用，都无法保证系统的绝对安全。尚术发现可证明一个较复杂的安全相关软件中不存在错误的方法，特别是规范和设计的错误。在开发高度完整性软件时采取但不仅限于以下原则：自项向下的设计方法
b）模块化；
e）开发生命周期每个阶段的验证；d）经验证的模块和模块库！
）清晰的文档：
可审核的文档：
e）确认测试。
这些原则以及相关的其他原则应正确应用。本标准规定了在每个软件安全完整性等级下证明其（保证能处于该安全完整性等级）所的保证等级。GB/T28808—2012/IEC62279:2002在得到或形成了系统安全需求规范后，分配给软件的安全功能和系统安全完整性等级就确定了，图2给出了应用本标准的功能步骤，井如下所示：a）定义软件密求规范，同时考虑软件结构。软件结构是为软件和软件安全完整性等级开发基本安全策璐的渠构（第5章、第8章和第９章）。b）根据软件质量保证计划软件安全完整性等级和软件生命周期来设计、开发和测试软件（第10章。
c）在自标硬件工集成软件（第12章）d）确认软件（第13章）
e）如果在运行过程中需要软件维护，那么可蒋适当运用本标准进行处理（第16章）。许多活动都是在软件开发过程中交叉进行的，这其中包括验证（第11章）、评估（第14章）和质量保证（第15章），
给出了由应用数据所配置的系统的求（第17章）。给出了从事软件开发人员能力的需求（第6章）。本标准没有强制要求使用特定的软件开发生命周期，但是给出了推荐的生命周期和文档集（第？章，图3和图4）。
针对5个软件安全完整性等级明确制定了各种技术和措施表格。表格见附录A。对表格交叉引用的是对每个技术或措施做了简要描述的、同时附带更多信息源做参考的文献目录。附录B列出了文献目录。
GB/T28808--2012/1FC62279:2002轨道交通通信、信号和处理系统控制和防护系统软件
1.1本标准规定了轨道交适控制和防护设备应用中可编程电子系统开发所需的规程和技术要求，适用于任何有意含安全性的领域。这些应用系统的范围涵盖了从安全苛求系统（如安全信号系统）到非安全奇求系统（如管理信息系统）。这些系统可能通末用用微处理器，可编程逻辑控制器，分布式多处现器系统，大规模集中处理器系统或者其他结构来实现1.2本标准只适用于软件以及软件和统之间的交互作用。1.30级以上的软件安至完整准等级用于失效可导致人员死亡后果的系统。然而，从经济或环境因索方面考愿也能采用高级别的安全完整性等级。1.4本标准适用轨道交通控制和防护系统开发和实现中的所有软件，包括一应用程导设
一操作系统
一支持工具
一一国公
应用程序设包括高级
1.5本标准还淡及了标准商用
1.6本标准还对
由应用数据
1.7本标准并不步及商务间
商务活动中着需被子细考虑，
1.8本标准入是追期性的
低级利
和工具
的健用。
要应用于新的开车
用，对于小的修收，仅16靠适用2规范性引用文件
题宜作
实求。
程序设
基本部
程逻辑空制器梯形逻辑）。
姐缤#
标准中的所有条款在任何
既自系统文当进
行大的改时才进行全面应
下列文件对于本文件命应用是不可少的。凡是注日期的用文件，注且期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包拍所有的修改单）适用，本文件。GB/T28809—2012轨道交通通#信和外轴范就信号用安全相关电子系统（IEC624252007,IDT)
IEC60050-191国际电工词汇第19l章：可靠性和服务质量［nternalionalelectratechnicalvocabulary(lEV)-Chapter 19]:Dependability and qualityof service]IEC62278轨道交通可靠性、可用性.可维修性和安全性（RAMS)规范及示例[Railwayapplica-lions--Speceitication and demoristration of reliability, availability, maintainahility and safety (RAMS)]IEC62280-1铁路设施通信、信号和处理系统第【部分：在封闭的传输系统中有关通信安全(Railway applications--Commnunication. signalling and procrssing syslems-Part I:Safrry-relatedtommunication in closed transmission systems)IEC62280-2铁路设施通信、信号和处理系统第2部分：在开放的传输系统中有关通信安全(Railway applications--Communication, signalling and processing systems-Part 2: Safery-relutedGB/T 28808-2012/IFC 62279:2002communicationinopentransmissionsystems)[SO/IEC2382（所有部分）信息技术词汇（lnformationterhnology一Vocabulary）IS)/IEC9126（所有部分）软件工程产品质量（Softwareengineering—Productquality）ISO9000：2000\质量管理体系基础和术语（Qualirymanagementsystems-Fundainentals&nd vocabulary)
IS09000-3：1997\质量管理和质室保证标准第3部分：1SO9001：1994应用于计算机软件开发，供应，安装和维护的指南（Qualitymanagement and qualityassurance slandards一Part 3：Guidelinesfor the application of IS0 900l: l994 to the development, supply, installation and maintenance oicomputer software)
ISO9001：1994）质量系统设计、开发、生产、安装和维修中的质量保证模型（Qualitysystems-Model for quslity assurance in design, developnent, production, instailation and servicing.1EEF6J0,12软件工程术语集（[EEEstandardglossaryofsoftwareengineeringterminology）3术语和定义
[SO9000:2000、IEC60050-191、1SO/1EC23821S0/IEC9126、IEEE610.12界定的以及下列术语和定义适于本文件。
评估assessment
用下确定设计机构和确认员所完成的产品是否符合规定的要求和判定产品是否达到预期目的的分析过程。
评估员assessor
受委托执行评估的人员或者机构。3. 3
可用性avatlability
在要求的外部资源得到保证的前提下，产品在规定的条件下和规定的时刻或时间区间内处于可执行规定功能状态的能力。
商业通用软件commercial off-the-shelf（coTs）sofiware市场需求所定义，市场已存在且其目标满足性已得到广大商业用户证实的软件。3.5
设计机构designauthority
负责提出实现特定需求的设计方案，并监控后期的开发和系统在待定环境下工作的实体。3.6
设计者desigaer
个或多个由设计机构指派的人员，他们承担需求分析并将特定需求转化成可接受且有相应安全完整性的设计方案。
元素elcment
被确认为基本单元或基本组件的某产品的一部分。一个元素可是简单的，也可是复杂的。1）IS)9000,ISO9000-3.ISO9001已有新版文件，其中ISO9500-3文件由15O/IEC90003代替，相关文件对应的国家标准信息见参考文献。
错误error
GB/T28808-—2012/IEC62279:2002可能导致非预期的系统行为或失效的与期望设计之间的偏差。失效failure
与规定的系统行为产生偏差。失效是系统错误或故障的结果。3.10
故障fault
一种能导致系统错误或失效的不正常状态.故障可是系统性的或随机性的。3.11
避错faultavoidance
在系统设计和构造的过程中为避免引人放障而采用的设计技术。3.12
容错fault tolerance
在出现有限数量的软硬件故障的情况下，系统能继续提供正确的规定服务的内嵌能力。3.13
固件 firmware
以功能独立于主存储器方式存储的指令和相关数据的有序集合（通常在ROM中）。3.14
通用软件generic software
只要提供应用相关的数据就可应用于多种系统装置的软件。3.15
实现者implementer
由设计机构委派，具体实现特定设计的一个或多个人员。3. 16
产品product
为满足特定需求，收集元素并进行互连以形成一个系统，子系统或者设备。产品可被视为完全出软件或者文档索构成。
可编程逆辑控制器prograrmmablelogieconiroller：LC具备用户可编程存储器、能实现规定功能的固态控制系统。3.18
可靠性reliabilily
产品在规定的条件下和规定的时间区间（，，）内完成规定功能的能力。3.19
需求可追溯性目标requirementtraceabilily确保所有的需求能被证明已得到满足。3.20
风险risk
某特定危害事件的频度或概率和后果的组合。3.21
安全性safety
免除不可接受等级的风险。
GB/T 28808—2012/1EC 62279:20023.22
安全主管部门 safety authority负贡证实安全相关系统适于工作并符合法令、规章规定的安全需求的实体。3.23
安全相关软件safely-relatedsoftware负有安全宽任的软件。
软件saftware
出程序、流程、规则和系统运行相关的文档组成的智力产物。注：软件理立于传输介质
软件生命周期softwarelircycle的时期内发生的活动。典型软件生带周期包括需求阶段、开发从软件构思开始到软件停用为
阶段、测试阶段、渠成阶设、安装桥段和维护阶段。3.26
软件可维护性
software maintainability
系统能被修收以正故障，改进性能或具他特作3.27
软件维护
so ware maintenante
在软件套最终用户接收后
性等级
软件安全完整
括动或
softwre safety iniegrity leve一组分统数宁，它确定了
系统安全完整性等级
欧件故障降
system safety integ ity Fey
表示系统能满足双定安全特性性置信度的数3.30
tragability
可追溯性
的目的在
政等增加或正轮件的功能。
适当水
用的技术和措范。
能在开发过程中确定两个成者多个产品之间关系的程度，尤其是那单与其体次录关系的。
确认yalidation
通过测试和分析，表明产品在各个方面符合规定需求的证明行为，3.32
确认员
validator
被委派来做确认工作的人或者代理。3.33
验证verification
品构成前/后代或主
通过测试和分析，表明系统生命周期各阶段的输出符合前一阶段需求的一种判定行为。3.34
验证员
verificr
被委派来做验证工作的人或代理。4
4目标和一致性
4.1在以下每项条款中,将详细地描述其目标和要求。GB/T28808—2012/IEC62279:20024.2为与本标准一敬，应证明软件满足安全完整性等级规定的每顶要求，从而表明实现了条款目标。4.3如果一个需求含有“达到软件安全完性等级的要求“的语句，则表示可用一-系列的技术和措施来满足该求。
4.4在4.3的前提下，宜使用本标准给出的详纸表格来帮助选择合适的技术和措施达到软件安全完整性等级要求。
4.5如果在表格中列为极力推荐（HR）的某一技术或措施不被采用，那么软件质量保证计划或软件质保证计划参考的其他文件宜详细说明使用该技不的理并有相应记录。如果使用了表格认可的技术组合，可不说明或记录理由
4.6如果一项格术提及的技术或增施被建议使用，那么应记证相应技术或措施是否能有效地实现特定要求和整体自标，并生软件质量保证计划中或其引用的其他文件中相应的记录。4.7应通过检查本标准所要求的文档、其他客观证据、审核和见证测试来评估是否符合特殊条款的要求和表格中详细出的皮术和措施要求。4.8本标准带要使肩
列出。
5软件安金完整性等级
5.1目标
定义软件的安全完整性
5.2要求
5.2.1依据
EC6278GH1
一系统需求规克；
一系统安生需求贝范！
一系统结构指述；
一系统安全计划
其中包括：
一安全功能；
—一系统配置或体系结构；
—硬件可靠性需求
一安全完整性能求。
中所要求的并在参考材料中详细软件安全完整性等级应达到IEC62278规定的安全完整性等级的一般流程确定。5.2.2应在系统中软件应用的风险等级和系统安全完整件等级的基础上，决定需要的软件安全完整性等级。
5.2.3如没有进-一步防范措施，软件安全完整性等级不应低于系统安全完整性等级，然而，如果有在软件模块失效时能避免系统进人不安全状态的防护机制，则可降低模块的软件安全完整性等级5.2.4应考虑可能导致以下危害后果的风险：一人员死亡；
一人员的受伤或致病；
GB/T 28808-—2012/IEC 62279:2002环境的污染
—财产损失或损坏。
5.2.5风险可被定量化.但无法以同样方式规定软件安全完整性，因此，软件安全完整性等级应选用以下五个等级之一：
一一软件安全完整性等级4，对应等级描述为“非常高”一软件安全完整性等级3，对应等级描述为\高”一软件安全究整性等级2,对应等级描述为“中等”！一一软件安全完整性等级1，对应等级捕述为“低”1一软件安全完整性等级0，对应等级描述为“非安全相关”。5.2.6在软件需求规范中应规定软件安全完整性等级（见第8章），如果不间的软件组件有不同的软件安全完整些等级，应在软件结构规范中加以规定（见第9章）。6人员和职责
6.1目标
确保所有对软件负有责任的人员都有能力搬行其职责。6.2要求
6.2.1作为最低要求，供应商和/或开发商以及客户执行1SO9000-3：1997中有关TS09001:1994实施的猪南要求，
6.2.2除软件安全完整性等级0以外，安全过穆应在一个适当的安全组织的控制下完成。该组织遵从GB/T28809一2012\安全管理证据”条款中\安全组织”子条款要求。6.2.3软件生命周期各阶段（包括管理活动）涉及的所有人员应经过适当的培训，具有适当的经验和资质。
除软件安全完整性等级以外，对于特定的应用，极力推荐对软件生命周期各阶段（包括管理活6.2. 4F
动）涉及的所有人员的培训、经验和资质进行证实。6.2.5应在软件质量保证计划中记录上述子条款(6.2.4)所指的证实，适当包括能胜狂以下领域能力的证据：
的）道合应用领域的工程；
b）软件工程；
计算机系统工程：
d）安全工程，
法规握架。
应为软件指定独立评估员。同时执行6.2.10和14.4.1。应赋予评估人员足够的权威来实现对软件的评估。6.2.71
费穿整个软件生命周期，报据软件安全完整性等级所要求的程度，所涉及的舒方应是独立的，与图5所示-致，解释如下：
一在各个软件安全完整性等级，评估员应由安全主管部门认可，除6.2.10规定的情况外，都应独立于供应商。
一一设计人员/实现者、验证员和确认员可同属一个公司，但至少要满足以下独立性规定：。软件安全完整性等级0：没有限制，设计人员/实现者、验证员和确认员可是同一人。。软件安全完整性等级1和2:验证员和确认员可是同一人，但他们不应又是设计者/实现者。设计人员/实现者、验证员和确认员都能向项目经理报告。6
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。
中华人民共和国国家标准
GB/T 28808—2012/IEC 62279.2002轨道交通
通信、信号和处理系统
控制和防护系统软件
Railway applications--Communication ,signaling and processing systcms-Software for railway control and protection systems(IEC 62279;2002,1DT)
2012-11-05发布
中华人民共和国国家质量监督检验检疫总局中国国家标准化管理委员会
2013-02-01实施
规范性引用文件
术语和定义
日标和一致性
软件安全完整性等级
5.2要求
6人员和职责
6.1目标．
5.2要求
7生命周期和文挡
7.1目标
7.2要求
8软件需求规范
8.2输人文档
8.3输出文档
8.4要求··
9软件结构
9.1目标.
9.2输入文档
输出文档，
要求·
10软件设计和实现
输人文档
输出文档
11软件验证和测试
输人文档
输出文档
GB/T 28808--2012/IEC 62279:2002T
GB/1 28808—2012/JEC 62279:200212软件/硬件集成
12.2输人文档
12.3输出文档
12.4要求
18软件确认
13.1目标
13.2输人文档
13.3输出文档
13.4要求
14软件评估
14.2输人文档
14.3输出文档
15软件质量保证
15.2输人文档
输出文档
16软作维护
16.2输人文档
16.3输出文档
15.4要求
17基于应用数据配置的系统
17.2输人文档
17.3输出文档
17.4要求
附录A（规范性附录）技术和措施的选择推则录B（资料性附录）技术参考资料附录NA（资料性附录）与规范性引用国际文件有关的我国文件16
本标推按照G日/T1.1一2009给出的规则起草，GB/T28808—2012/IEC62279:2002本标准采用翻译法等同采用IEC62279:2002轨道交通通信、信号和处理系统控制和防护系统软件。
与本标雄中规范性引用文件有一致性对应关系的我国文件见附录NA。本标准做了下列编辑性修改：
—将第3章中引用的IEC60050-191.ISO/IEC2382、1S0/EC9126、IEEE6J0.12文件补充到第2章规范性引用文件中；
修改了1FC62279：2002中第2章的脚注1，因为[EC62278已发布：脚注1改为对IS09000ISO9000-3.IS()9001提存在新版文件—采用等同来用IEC62425：2007的GB/T28809—2012代替EVV50129；一修订正文中引用的ISO9000、ISO9000-3、ISO9001的版本号，与第2章产明的版本号一致，—IEC62279：2002的一级子列项编号采用的是i）、i），或1）,2）、\本标准中统一修改为字母编号形式:a)、h)、1
—一附录B中，对每章内的单列一行的黑体字符“目标”、“描述\和“参考文献”进行编号，以符合中文习惯。免费标准下载网bzxz
本标准由中华人民共和国铁道部提出。本标准由全国牵引电气设备与系统标准化技术委员会（SAC/TC278)归口。本标准主要起草单位：同济大学，铁道部标推计量研究所。本标准参加起草单位：株洲南车时代电气股份有限公司、北京全路通信信号研究设计院。本标准主要起草人:徐中伟、赵天时、王奇。本标雅参加起草人：范椎成、孙超、严云升、陈邦兴、黄银霞、呼爱蝉、牛道恒。GB/T28808—2012/IEC62279:2002引言
本标准与GB/T21562（IEC62278）和GB/T28809—2012（IEC62425：2007,IDT)配套使用。GB/T21562（IEC62278）适用于大范围的系统尚题.而GB/T28809-2012（1E062425：2007，JDT)道用于整个轨道交通控制和防护系统中某单个系统的批准试程。为提供满足安全完整性要求的软件，本标准关注于通过更全面考虑后提出软件安全完整性要求所要采用的方法。本标准从IEC/TC 65第九工作组（WG9)早期T.作中得到很多指导。同时，对铁路信号工程师协会（IRSE）的工作也加以了考虑，特别是关注相同主题的1尽技术报告。本标准的关键思想是其对软件安全完性等级的考。软件失效的后果越严重，软件安全完整性等级也就越高。
标准确定了从最低0级到最高4级的5个软件安全完整性等级的技术和措施。其中1级～4级指的是安全相关软件,0级指的是非安全相关软件。将○级包括进本标准是为了让非安全相关系统软件开发向安全相关系统软件开发实现顺利过渡。附表给出了各个软件安全完整性等缀和非安全相关等级要求的技术和措施。在本版本中，1级和2级的技术要求相同,3级和4级的要求相同。本标准没有给出某一风险应适用于哪个软件安全完整性等级的具体指导意见。这一结论需要考虑诸多浆，包括应用的特性、其他系统承担的安全功能范围以及社会和经济因素。软件安全功能的分配由GB/T21562（IEC62278）和GB/T28809--2012（JEC62425：2007，IDT)规定。
本标准规定了满足这些需求的必要措施。该过见图1。GB/T21562(IEC62278)和GB/T28809—2012(IEC62425:2007.IDT)需采用系统性的方法，以：a）确定危害、风险和风险准则：b）为满足风险准则，确定必要的风险降低（措施）；c）为实现所需的风险降低，为必要的安全防护措施定义一个全面的系统安全需求规范：d）选择一个合适的系统结构：
规划、监督和控制那些把系统安全诺求规范变成安全性能（或安全完整性）已确认的安全相关e
系统。
在将该规范分解到由安全相关系统和组件组成的设计当中时.对安全完整性等级的进一步分配就完成了，并最终形所带的软件安全完整性等级。目前，无论是质域保证法（即避错措施)还是软件容错法的应用，都无法保证系统的绝对安全。尚术发现可证明一个较复杂的安全相关软件中不存在错误的方法，特别是规范和设计的错误。在开发高度完整性软件时采取但不仅限于以下原则：自项向下的设计方法
b）模块化；
e）开发生命周期每个阶段的验证；d）经验证的模块和模块库！
）清晰的文档：
可审核的文档：
e）确认测试。
这些原则以及相关的其他原则应正确应用。本标准规定了在每个软件安全完整性等级下证明其（保证能处于该安全完整性等级）所的保证等级。GB/T28808—2012/IEC62279:2002在得到或形成了系统安全需求规范后，分配给软件的安全功能和系统安全完整性等级就确定了，图2给出了应用本标准的功能步骤，井如下所示：a）定义软件密求规范，同时考虑软件结构。软件结构是为软件和软件安全完整性等级开发基本安全策璐的渠构（第5章、第8章和第９章）。b）根据软件质量保证计划软件安全完整性等级和软件生命周期来设计、开发和测试软件（第10章。
c）在自标硬件工集成软件（第12章）d）确认软件（第13章）
e）如果在运行过程中需要软件维护，那么可蒋适当运用本标准进行处理（第16章）。许多活动都是在软件开发过程中交叉进行的，这其中包括验证（第11章）、评估（第14章）和质量保证（第15章），
给出了由应用数据所配置的系统的求（第17章）。给出了从事软件开发人员能力的需求（第6章）。本标准没有强制要求使用特定的软件开发生命周期，但是给出了推荐的生命周期和文档集（第？章，图3和图4）。
针对5个软件安全完整性等级明确制定了各种技术和措施表格。表格见附录A。对表格交叉引用的是对每个技术或措施做了简要描述的、同时附带更多信息源做参考的文献目录。附录B列出了文献目录。
GB/T28808--2012/1FC62279:2002轨道交通通信、信号和处理系统控制和防护系统软件
1.1本标准规定了轨道交适控制和防护设备应用中可编程电子系统开发所需的规程和技术要求，适用于任何有意含安全性的领域。这些应用系统的范围涵盖了从安全苛求系统（如安全信号系统）到非安全奇求系统（如管理信息系统）。这些系统可能通末用用微处理器，可编程逻辑控制器，分布式多处现器系统，大规模集中处理器系统或者其他结构来实现1.2本标准只适用于软件以及软件和统之间的交互作用。1.30级以上的软件安至完整准等级用于失效可导致人员死亡后果的系统。然而，从经济或环境因索方面考愿也能采用高级别的安全完整性等级。1.4本标准适用轨道交通控制和防护系统开发和实现中的所有软件，包括一应用程导设
一操作系统
一支持工具
一一国公
应用程序设包括高级
1.5本标准还淡及了标准商用
1.6本标准还对
由应用数据
1.7本标准并不步及商务间
商务活动中着需被子细考虑，
1.8本标准入是追期性的
低级利
和工具
的健用。
要应用于新的开车
用，对于小的修收，仅16靠适用2规范性引用文件
题宜作
实求。
程序设
基本部
程逻辑空制器梯形逻辑）。
姐缤#
标准中的所有条款在任何
既自系统文当进
行大的改时才进行全面应
下列文件对于本文件命应用是不可少的。凡是注日期的用文件，注且期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包拍所有的修改单）适用，本文件。GB/T28809—2012轨道交通通#信和外轴范就信号用安全相关电子系统（IEC624252007,IDT)
IEC60050-191国际电工词汇第19l章：可靠性和服务质量［nternalionalelectratechnicalvocabulary(lEV)-Chapter 19]:Dependability and qualityof service]IEC62278轨道交通可靠性、可用性.可维修性和安全性（RAMS)规范及示例[Railwayapplica-lions--Speceitication and demoristration of reliability, availability, maintainahility and safety (RAMS)]IEC62280-1铁路设施通信、信号和处理系统第【部分：在封闭的传输系统中有关通信安全(Railway applications--Commnunication. signalling and procrssing syslems-Part I:Safrry-relatedtommunication in closed transmission systems)IEC62280-2铁路设施通信、信号和处理系统第2部分：在开放的传输系统中有关通信安全(Railway applications--Communication, signalling and processing systems-Part 2: Safery-relutedGB/T 28808-2012/IFC 62279:2002communicationinopentransmissionsystems)[SO/IEC2382（所有部分）信息技术词汇（lnformationterhnology一Vocabulary）IS)/IEC9126（所有部分）软件工程产品质量（Softwareengineering—Productquality）ISO9000：2000\质量管理体系基础和术语（Qualirymanagementsystems-Fundainentals&nd vocabulary)
IS09000-3：1997\质量管理和质室保证标准第3部分：1SO9001：1994应用于计算机软件开发，供应，安装和维护的指南（Qualitymanagement and qualityassurance slandards一Part 3：Guidelinesfor the application of IS0 900l: l994 to the development, supply, installation and maintenance oicomputer software)
ISO9001：1994）质量系统设计、开发、生产、安装和维修中的质量保证模型（Qualitysystems-Model for quslity assurance in design, developnent, production, instailation and servicing.1EEF6J0,12软件工程术语集（[EEEstandardglossaryofsoftwareengineeringterminology）3术语和定义
[SO9000:2000、IEC60050-191、1SO/1EC23821S0/IEC9126、IEEE610.12界定的以及下列术语和定义适于本文件。
评估assessment
用下确定设计机构和确认员所完成的产品是否符合规定的要求和判定产品是否达到预期目的的分析过程。
评估员assessor
受委托执行评估的人员或者机构。3. 3
可用性avatlability
在要求的外部资源得到保证的前提下，产品在规定的条件下和规定的时刻或时间区间内处于可执行规定功能状态的能力。
商业通用软件commercial off-the-shelf（coTs）sofiware市场需求所定义，市场已存在且其目标满足性已得到广大商业用户证实的软件。3.5
设计机构designauthority
负责提出实现特定需求的设计方案，并监控后期的开发和系统在待定环境下工作的实体。3.6
设计者desigaer
个或多个由设计机构指派的人员，他们承担需求分析并将特定需求转化成可接受且有相应安全完整性的设计方案。
元素elcment
被确认为基本单元或基本组件的某产品的一部分。一个元素可是简单的，也可是复杂的。1）IS)9000,ISO9000-3.ISO9001已有新版文件，其中ISO9500-3文件由15O/IEC90003代替，相关文件对应的国家标准信息见参考文献。
错误error
GB/T28808-—2012/IEC62279:2002可能导致非预期的系统行为或失效的与期望设计之间的偏差。失效failure
与规定的系统行为产生偏差。失效是系统错误或故障的结果。3.10
故障fault
一种能导致系统错误或失效的不正常状态.故障可是系统性的或随机性的。3.11
避错faultavoidance
在系统设计和构造的过程中为避免引人放障而采用的设计技术。3.12
容错fault tolerance
在出现有限数量的软硬件故障的情况下，系统能继续提供正确的规定服务的内嵌能力。3.13
固件 firmware
以功能独立于主存储器方式存储的指令和相关数据的有序集合（通常在ROM中）。3.14
通用软件generic software
只要提供应用相关的数据就可应用于多种系统装置的软件。3.15
实现者implementer
由设计机构委派，具体实现特定设计的一个或多个人员。3. 16
产品product
为满足特定需求，收集元素并进行互连以形成一个系统，子系统或者设备。产品可被视为完全出软件或者文档索构成。
可编程逆辑控制器prograrmmablelogieconiroller：LC具备用户可编程存储器、能实现规定功能的固态控制系统。3.18
可靠性reliabilily
产品在规定的条件下和规定的时间区间（，，）内完成规定功能的能力。3.19
需求可追溯性目标requirementtraceabilily确保所有的需求能被证明已得到满足。3.20
风险risk
某特定危害事件的频度或概率和后果的组合。3.21
安全性safety
免除不可接受等级的风险。
GB/T 28808—2012/1EC 62279:20023.22
安全主管部门 safety authority负贡证实安全相关系统适于工作并符合法令、规章规定的安全需求的实体。3.23
安全相关软件safely-relatedsoftware负有安全宽任的软件。
软件saftware
出程序、流程、规则和系统运行相关的文档组成的智力产物。注：软件理立于传输介质
软件生命周期softwarelircycle的时期内发生的活动。典型软件生带周期包括需求阶段、开发从软件构思开始到软件停用为
阶段、测试阶段、渠成阶设、安装桥段和维护阶段。3.26
软件可维护性
software maintainability
系统能被修收以正故障，改进性能或具他特作3.27
软件维护
so ware maintenante
在软件套最终用户接收后
性等级
软件安全完整
括动或
softwre safety iniegrity leve一组分统数宁，它确定了
系统安全完整性等级
欧件故障降
system safety integ ity Fey
表示系统能满足双定安全特性性置信度的数3.30
tragability
可追溯性
的目的在
政等增加或正轮件的功能。
适当水
用的技术和措范。
能在开发过程中确定两个成者多个产品之间关系的程度，尤其是那单与其体次录关系的。
确认yalidation
通过测试和分析，表明产品在各个方面符合规定需求的证明行为，3.32
确认员
validator
被委派来做确认工作的人或者代理。3.33
验证verification
品构成前/后代或主
通过测试和分析，表明系统生命周期各阶段的输出符合前一阶段需求的一种判定行为。3.34
验证员
verificr
被委派来做验证工作的人或代理。4
4目标和一致性
4.1在以下每项条款中,将详细地描述其目标和要求。GB/T28808—2012/IEC62279:20024.2为与本标准一敬，应证明软件满足安全完整性等级规定的每顶要求，从而表明实现了条款目标。4.3如果一个需求含有“达到软件安全完性等级的要求“的语句，则表示可用一-系列的技术和措施来满足该求。
4.4在4.3的前提下，宜使用本标准给出的详纸表格来帮助选择合适的技术和措施达到软件安全完整性等级要求。
4.5如果在表格中列为极力推荐（HR）的某一技术或措施不被采用，那么软件质量保证计划或软件质保证计划参考的其他文件宜详细说明使用该技不的理并有相应记录。如果使用了表格认可的技术组合，可不说明或记录理由
4.6如果一项格术提及的技术或增施被建议使用，那么应记证相应技术或措施是否能有效地实现特定要求和整体自标，并生软件质量保证计划中或其引用的其他文件中相应的记录。4.7应通过检查本标准所要求的文档、其他客观证据、审核和见证测试来评估是否符合特殊条款的要求和表格中详细出的皮术和措施要求。4.8本标准带要使肩
列出。
5软件安金完整性等级
5.1目标
定义软件的安全完整性
5.2要求
5.2.1依据
EC6278GH1
一系统需求规克；
一系统安生需求贝范！
一系统结构指述；
一系统安全计划
其中包括：
一安全功能；
—一系统配置或体系结构；
—硬件可靠性需求
一安全完整性能求。
中所要求的并在参考材料中详细软件安全完整性等级应达到IEC62278规定的安全完整性等级的一般流程确定。5.2.2应在系统中软件应用的风险等级和系统安全完整件等级的基础上，决定需要的软件安全完整性等级。
5.2.3如没有进-一步防范措施，软件安全完整性等级不应低于系统安全完整性等级，然而，如果有在软件模块失效时能避免系统进人不安全状态的防护机制，则可降低模块的软件安全完整性等级5.2.4应考虑可能导致以下危害后果的风险：一人员死亡；
一人员的受伤或致病；
GB/T 28808-—2012/IEC 62279:2002环境的污染
—财产损失或损坏。
5.2.5风险可被定量化.但无法以同样方式规定软件安全完整性，因此，软件安全完整性等级应选用以下五个等级之一：
一一软件安全完整性等级4，对应等级描述为“非常高”一软件安全完整性等级3，对应等级描述为\高”一软件安全究整性等级2,对应等级描述为“中等”！一一软件安全完整性等级1，对应等级捕述为“低”1一软件安全完整性等级0，对应等级描述为“非安全相关”。5.2.6在软件需求规范中应规定软件安全完整性等级（见第8章），如果不间的软件组件有不同的软件安全完整些等级，应在软件结构规范中加以规定（见第9章）。6人员和职责
6.1目标
确保所有对软件负有责任的人员都有能力搬行其职责。6.2要求
6.2.1作为最低要求，供应商和/或开发商以及客户执行1SO9000-3：1997中有关TS09001:1994实施的猪南要求，
6.2.2除软件安全完整性等级0以外，安全过穆应在一个适当的安全组织的控制下完成。该组织遵从GB/T28809一2012\安全管理证据”条款中\安全组织”子条款要求。6.2.3软件生命周期各阶段（包括管理活动）涉及的所有人员应经过适当的培训，具有适当的经验和资质。
除软件安全完整性等级以外，对于特定的应用，极力推荐对软件生命周期各阶段（包括管理活6.2. 4F
动）涉及的所有人员的培训、经验和资质进行证实。6.2.5应在软件质量保证计划中记录上述子条款(6.2.4)所指的证实，适当包括能胜狂以下领域能力的证据：
的）道合应用领域的工程；
b）软件工程；
计算机系统工程：
d）安全工程，
法规握架。
应为软件指定独立评估员。同时执行6.2.10和14.4.1。应赋予评估人员足够的权威来实现对软件的评估。6.2.71
费穿整个软件生命周期，报据软件安全完整性等级所要求的程度，所涉及的舒方应是独立的，与图5所示-致，解释如下：
一在各个软件安全完整性等级，评估员应由安全主管部门认可，除6.2.10规定的情况外，都应独立于供应商。
一一设计人员/实现者、验证员和确认员可同属一个公司，但至少要满足以下独立性规定：。软件安全完整性等级0：没有限制，设计人员/实现者、验证员和确认员可是同一人。。软件安全完整性等级1和2:验证员和确认员可是同一人，但他们不应又是设计者/实现者。设计人员/实现者、验证员和确认员都能向项目经理报告。6
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。