技术安全报告模板.docx

技术安全报告模板.docx

《技术安全报告模板.docx》由会员分享，可在线阅读，更多相关《技术安全报告模板.docx（8页珍藏版）》请在冰豆网上搜索。

技术安全报告模板

技术安全报告

XXXX年XX月

版本记录

版本号

日期

修改章节

修改内容及说明

编制者

V

XXXXXXXX

编制者：

审核者：

项目负责人：

1.前言

提示：

提供设计的总体描述，包括对安全所依赖的技术安全准则和依据本标准系统/子系统/设备所声明达到的安全程度的概述

提示：

对系统进行概括性描述，一段话即可。

技术安全报告是安全例证中的重要组成部分，主要对***系统安全性的技术证据进行记录。

本报告是安全相关系统的强制性文档，对***系统设计中确保安全性所涉及到的所有支撑证据的技术原则进行阐述，如设计原则、测试规范与结论、安全分析与结论等。

1.1.范围

提示：

需要描述本文档描述系统的范围，主要说清楚被认证系统包含什么，那些属于这个项目负责的范围，那些不属于，对于后续应用，系统提供什么样的接口、流程等支持。

1.2.文档目的

提示：

本技术安全报告符合EN50129:

2003的要求，主要目标是从技术安全的角度，论述***系统正确运行的技术保障、安全保障，以及对故障的分析和处理措施、系统的安全相关应用环境等，为确认系统的安全完整性提供相应的技术安全证据。

1.3.假设与限制

提示：

应对被认证系统存在的假设和限制分开进行描述

1.4.参考文件

1.4.1.强制性参考标准

提示：

EN50126-1：

1999

铁路应用：

可靠性、可用性、可维护性和安全性（RAMS）规范和说明；

RailwayApplication:

TheSpecificationandDemonstrationofReliability,Availability,MaintainabilityandSafety（RAMS）

EN50128：

2001

铁路应用：

铁路控制和防护系统的软件；

RailwayApplication:

SoftwareforRailwayControlandProtection

EN50129：

2003

铁路应用：

铁路控制系统领域的安全相关电子系统；

RailwayApplication:

Communication,SignallingandProcessingSystems-SafetyRelatedElectronicSystemsforSignalling

其他技术标准（EN，IEC，TB，Subsets等）

1.4.2.参考文档

提示：

项目文档、过程记录、会议记录、相关的安全证据等。

1.4.3.开发工具

提示：

应列出为系统的开发、测试、验证与确认和管理活动符合安全等级要求而使用的工具

1.5.缩写与术语

2.系统概述

提示：

对系统整体进行描述。

系统的定义；

本系统与其他系统的结构图（系统内部结构、接口等），对系统功能和接口进行简要的介绍；

系统的产品结构（系统组成、不同子系统/模块之间的依赖关系）

3.功能正确运行的保障

3.1.系统结构描述

提示：

本部分应包含对系统/子系统/设备设计的总体描述。

总体描述应有足够的深度以便能清晰地理解系统所用的原则和技术

描述系统总体的结构，可以采用结构图辅以文字描述的方式。

注意，应从系统-子系统-模块的层次角度逐层进行说明，逐步细化到硬件与软件的层次

需要明确区分系统中安全相关部分和非安全相关部分，并给出相应的分析证据。

对系统的整体框架进行描述，若系统、子系统或产品为外购或成熟产品，且产品存在安全证据或安全相关应用条件，则在简要描述后，引用安全证据并描述系统实现过程中符合安全相关应用条件。

3.2.接口定义

提示：

需要考虑人机接口（包括操作接口、配置接口、维护接口等），系统外部接口（功能/逻辑的、物理的），系统内部接口（功能/逻辑的、物理的）

3.2.1.人机接口

提示：

人机界面接口主要用于操作人员对系统的操作、配置与维护工作。

主要包括系统运行显示接口、操作接口、配置接口、维护接口和标识等。

需要根据系统实际情况进行描述，并引用相关的接口定义文档。

3.2.2.系统外部接口

提示：

应给出总体描述系统外部接口的图和文字，并引用相关的接口定义文档。

应通过图和文字的方式，分别对每个外部接口从物理层次和功能/逻辑层次进行说明，具有内容可以引用相关的接口定义文档，但是应该描述接口的基本信息，每个接口在物理层次和功能/逻辑层次符合的标准、规范或要求，接口是否传输安全相关信息已经确保信息安全传输的实现方式，并引用相关证据。

3.2.3.内部接口

提示：

要求同“系统外部接口”

3.3.系统需求规范的实现

提示：

应论证在系统/子系统/设备需求规格说明书里规定的运行功能需求是如何通过设计来实现的。

提示：

应对系统需求规范进行一个总体描述，应包括：

需求规范的来源/产生方式（标准、规范、环境、其他相关系统、接口、平台等）及相关证据

需求规范涉及到的方面（功能、性能、RAM、接口等）及相关证据

需求规范表述方式（结构化描述或半形式化描述）及相关证据

需求的管理方式（需求管理工具、需求的追踪关系、需求评审、需求变更）及相关证据

应简单描述系统需求规范的实现原理和技术，并引用相关证据。

应描述系统研发各个生命周期的验证与测试活动，通过引用相关文档证明系统生命周期的每个阶段都执行了恰当的验证/测试活动，所有生命周期阶段的阶段成果满足阶段预期。

应描述需求的确认内容，应包括：

需求与测试案例的追踪关系及相关证据

测试的执行过程及相关证据

测试的结果及相关证据以及对需求的追踪关系

具体内容，可以引用相关文档。

3.4.安全需求规范的实现

提示：

应论证规定的安全功能需求是如何通过设计来实现的。

提示：

应对安全需求规范进行一个总体描述，应包括：

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

危险分析的描述（包括流程、进行危险分析所对应的阶段、分析结论）及相关证据

HazardLog的描述（包括管理/危险登记/沟通流程、记录的内容）及相关证据

安全需求规范的表述方式（结构化描述或半形式化描述）及相关证据

安全需求的管理方式（需求管理工具、需求的追踪关系（应说明与HazardLog中Hazard的关系）、需求评审、需求变更）及相关证据

应简单描述安全需求规范的实现原理和技术（应参考EN50129附录E.4、E.5、E.6，进行逐一的简要说明），并引用相关证据。

应描述系统研发各个生命周期的验证与测试活动涉及所有安全相关内容（安全需求、设计、实现）。

应描述确认内容涉及所有安全需求。

3.5.硬件功能正确性的保障

提示：

应描述系统/子系统/设备的硬件结构，解释设计是如何达到所需的完整性。

包括需求规格说明和其它相关标准所拟定的以下几方面：

可靠性；

可用性；

可维护性；

安全性。

3.6.软件功能正确性的保障

提示：

应满足EN50128的需求。

本部分应包含或参考所有EN50128所需文档，尤其是软件确认报告和软件评估报告。

除此之外，应说明硬件与软件之间的相互作用，如果系统软件、工具是随硬件外购的软件数据配置过程定义。

4.故障影响

提示：

本节论证在发生随机硬件故障直至可能的系统故障时，系统/子系统/设备持续满足规定的安全需求的能力。

应包括：

单一故障影响：

对象的独立性：

单一故障检测：

故障检测后的措施（包括安全状态的保持）：

多重故障的影响：

系统故障的防护：

5.外界影响

提示：

本部分讨论系统/子系统/设备在规定的外界影响下正确、安全地运行的能力。

“正确运行”包括满足功能需求和安全需求两个方面。

6.安全相关应用条件

提示：

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

这些输入的安全相关应用条件的实现和分析，可以参见相关证据。

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

6.1.输入的安全相关应用条件

提示：

应对每个子系统传递到本项目的SRAC列表进行逐一说明，说明应包括：

编号、描述、处置措施、理由、是否需要传递给相关责任方、责任方是谁

6.2.责任方安全相关应用条件

提示：

应考虑无法关闭的本项目输入SRAC和本项目识别的危险，形成SRAC，并将这些SRAC传递给相关责任方。

应该根据不同责任方，分别通过表格进行说明每条SRAC，说明应包括：

编号、描述、来源、说明、理由，应该使用易于理解的非技术语言描述。

7.安全合格测试

提示：

本部分应包括证明在应用条件下成功完成系统功能的证据。