系统安全需求规范模板

系统安全需求规范

编制：审核：批准：

目录

1.简介 (5)

1.1.系统简介 (5)

1.2.文档目的 (5)

1.3.文档范围 (5)

1.4.与其它开发任务/文档的关系 (5)

1.5.术语和缩写词 (6)

1.6.系统安全侧定义 (6)

1.7.需求来源 (6)

1.8.需求编号原则 (7)

2.参考文档 (8)

3.系统安全需求规范 (9)

4.安全相关应用条件 (11)

4.1.从子系统输入的安全相关应用条件 (11)

4.2.由本项目向其他相关方提出的安全相关应用条件 (11)

5.假设及限制条件 (12)

6.隐患跟踪 (13)

1.简介

1.1.系统简介

提示：对系统进行简要介绍，包括系统的安全目标，安全评估的类型等。

1.2.文档目的

提示：阐明此文档的目的

通过本说明书描述应答器系统开发的安全需求，作为项目开发的指导性文件。

1.3.文档范围

本说明书规定了应答器系统的安全性要求，制定了保证系统安全的需求，以及可靠性、可用性、可维修性和安全性的相互作用。

1.4.与其它开发任务/文档的关系

提示：如需求和设计文档的关系

1.4.1 与其他开发任务的关系

BTM项目，接收应答器地面信息，传送到车载设备。

1.4.1 与其他文档的关系

本文档参照《系统定义》、《项目安全计划》编写。

本文档将作为系统开发设计依据。

1.5.术语和缩写词

可靠性 Reliability：系统在规定条件下河规定时间区间（t1，t2）内，完成所需功能的能力。

可用性 Availability：在要求的外部资源得到保证的前提下，产品在规定的条件下和规定的时刻或时间区间内处于可执行规定功能状态的能力。

可维护性 Maintainability：在规定的条件下，使用规定的程序和资源进行维修时，对于给定使用条件下的产品在规定的时间区间内，能完成指定的实际维修工作的能力。

安全性 Safety：免除不可接受的风险影响的特性。

安全论据 Safety case：系统/产品符合规定安全要求的书面说明。

风险 risk：导致伤害的危害发生概率及伤害的严重等级。

MTBF Mean time between failure：系统/产品的平均故障间隔时间

故障模式 Fault mode：对于规定的要求功能，故障项目的一种可能的状态。安全完整性 Safety integrity：在所有规定的条件下系统于给定时间内满意地实现要求安全功能的可能性。

安全完整性级别（SIL）Safety integrity level：许多已规定的断续的数值之一，这些数值规定了分配给安全相关系统的安全功能的安全完整性级别。数值越大，安全完整性级别越高。

系统生命周期 System life cycle：从系统的构思开始到系统不能再使用被退役或淘汰的时间内所发生的活动。

1.6.系统安全侧定义

提示：定义系统的安全侧

1.7.需求来源

提示：说明安全需求规范的来源/产生方式（危险分析、标准、规范、Subsets、环境、已知的安全需求、外部的安全相关应用条件SRAC等）及相关证据

本需求根据UBSET-036要求编写。

CTCS系统安全规范要求提出

1.8.需求编号原则

提示：给出需求编号的原则和定义。文档下面描述的所有需求都要按照这个原则给出编号。

2.参考文档

系统需求规范

危险日志

EN 50126:1999 轨道交通-可靠性、可用性、可维修性和安全性规范及示例铁路信号可靠性安全性理论及证实郦萌吴芳美（编著）穆建成（审核）中国铁道出版社

SUBSET-036(ISSUE 2.4.1) FFFIS for Eurobalise

SUBSET-085(ISSUE 2.2.2) Test Specification for Eurobalise FFFIS GB/T 21562-2008 轨道交通可靠性、可用性、可维修性和安全性规范及示例

TB/T 3133-2006 铁路机车车辆电子产品的可靠性、可用性、可维修性和安全性

EN 50129-2003 铁路应用-通信、信号和处理系统-信号的安全相关电子处理系统

3.系统安全需求规范

提示：系统安全需求包括功能的安全完整度等级和THR要求、满足故障-安全设计原则以及安全功能需求等。

安全需求应有唯一标识。

每条安全需求都应注明其来源，例如铁道部要求，标准，规范，或追溯到危险日志中的某条危害源ID。

3.1 安全需求标识

安全需求有唯一标识：GX-YDQ-R-S

3.2 安全原则

3.2.1 CTCS技术规范的安全原则适用于应答器子系统。

3.2.2 安全信息的传输要从信息源至信息终点全程遵循信号安全的标准。传输通道应具有高可靠性、高安全性和高可用性。

3.2.3 能够检测到信道不良引起的传输错误，并采取相应的安全措施。

3.2.4 所有信息内容均有一定的有效时间要求（地面无源应答器的有效时间可视为无穷大，有源应答器的数据要定期刷新或重写）。

3.3 设计与制造

3.3.1 冗余设计（各个重要方面的冗余，如：信息的冗余，电源冗余，结构冗余）

3.3.2 硬件功能的检查

3.3.3 特殊的生产及测试工具

3.3.4 经过批准的合格的原材料

3.3.5 元件的筛选

3.3.6 故障反应

只能接受导向安全的故障，一般而言，如果出现故障，系统将导向安全侧，并降级使用。

3.3 系统应满足SIL4安全完善性等级要求。

满足故障安全设计

3.4 安全功能需求

3.4.1

系统安全需求可分层4次写，涵盖系统层、子系统层、内部接口、外部接口以及运营的安全需求。、

4.安全相关应用条件

提示：

对于那些不能被子系统/模块/接口实现的安全相关应用条件，将由子系统/模块/接口层次传递到本项目层次，并被本项目继承。

对于本项目层次无法满足的安全需求，会产生相应的安全相关应用条件，项目根据相关的途径，将安全相关应用条件传递给责任方。

4.1.从子系统输入的安全相关应用条件

提示：

应对每个子系统传递到本项目的安全相关应用条件列表进行逐一说明，说明应包括：编号、描述、处置措施、理由、是否需要传递给相关责任方、责任方是谁等。

4.2.由本项目向其他相关方提出的安全相关应用条件

提示：

应考虑无法关闭的本项目识别的危险，形成安全相关应用条件，并传递给相关责任方，如运营方、维护方、集成方等。对于需要运营方或维护方解决的安全相关应用条件，应该使用易于理解的非技术语言描述。应该根据不同责任方，分别通过表格进行说明每条安全相关应用条件，说明应包括：编号、描述、来源、理由、应用条件等。

5.假设及限制条件

提示：

对系统安全需求相关的假设及限制条件进行描述。

平均故障恢复时间（MTTR）为10小时

6.隐患跟踪

提示：

应对安全需求相应的隐患应采取的措施进行描述。