Railway Standard 铁路标准——keyword：SIL、RAMS

关键词：功能安全SIL、61508、50126、50128、50129，IN 20500-1988地下采矿铁路.轨距和轨道.标准类型和选择Underground mine railways; track gauges and rails; standard types and selection DIN 20501-1988矿山铁路.S30 钢...

Railway Standard 铁路标准 ——keyword：SIL、RAMS

• standard file
  • EN
    • EN50159
      • EN50159-1-2001：《 轨 道 交 通 通 信 、 信 号 和 处 理 系 统 第 1 部 分 ：封闭式传输系统中的安全相关通信》 （已废止）
      • EN50159-2-2001：《 轨 道 交 通 通 信 、 信 号 和 处 理 系 统 第 2 部 分 ：开放式传输系统中的安全相关通信》 （已废止）
      • EN50159：Railway applications –Communication, signaling and processing systems – Safety-related communication in transmission systems-20100 《轨道交通通信、信号和处理系统 传输系统中的安全相关通信》 ——GB/T 24339.1
        • 第1部分：封闭式传输系统中的安全相关通信
          • 前言
          • 引言
          • char
            • 范围
            • 规范性引用文件
            • 术语和定义
            • 参考结构
            • 传输系统特征和安全规程之间的关系
              • 功能完整性要求
              • 安全完整性要求
            • 安全规程要求
              • 总则
              • 安全相关设备间的通信
              • 安全相关设备与非安全相关设备之间的通信
              • 非安全相关设备间的通信
            • 安全编码要求
              • 总则
              • 安全目标
              • 安全编码的长度
          • 附录A（资料性附录）安全编码的长度
        • 第2部分：开放式传输系统中的安全相关通信
          • 前言
          • 引言
          • char
            • 范围
            • 规范性引用文件
            • 术语和定义
            • 参考结构
            • 传输系统的威胁源
            • 防护要求
              • 总则
              • 总体要求
              • 具体防护
            • 防护威胁措施的适用性
              • 概述
              • 威胁/防护矩阵
              • 安全编码和加密技术的选择和使用
          • 附录A（资料性附录）防护指南
          • 附录B（资料性附录）参考文献
          • 附录C（资料性附录）本部分使用指南
          • 附录D（资料性附录）开放式传输系统的威胁
    • EN50126
      • EN50126-1999（已废止）
      • EN50126-2017：Railway applications – The Specification and demonstration of Reliability, Availability, Maintainability and Safety (RAMS) 轨道交通——可靠性、可用性、可维修性和安全性规范及示例 ——GB/T 21562-2008 ——IEC 62278
        • EN50126-1-2017 《轨道交通可靠性、可用性、可维修性和安全性 （RAMS） 规范及示例 第 1 部分：通用RAMS 过程》
          • 第 5 章明确了轨道交通 ＲAMS 的概念，指出 ＲAMS 各要素之间的关系和影响因素，提出了降低 ＲAMS 风险的策略
          • 第 6 章规定了生命周期阶段的通用任务和ＲAMS 任务、风险评估、组织管理、文档要求、验证和确认以及独立安全评估的目标和活动
          • 第 7 章规定了 ＲAMS 活动在每个生命周期阶段的目标、活动和交付物
          • 第 8 章规定了安全论据的目的和内容。
          • 附录 A 给 出 了 ＲAMS 规 划 示 例
          • 附 录 B 给 出 了ＲAMS 参数示例
          • 附录 C 给出了风险矩阵和风险接受准则
          • 附录 D 给出了系统定义指南
        • EN50126-2-2017 《轨道交通可靠性、可用性、可维修性和安全性 （RAMS） 规范及示例 第 2 部分：安全系统方法/应用》
          • 第 5 章规定了安全流程，包括风险评估、风险识别和控制、风险评估修订
          • 第 6 章规定了安全演示和验收流程
          • 第 7 章规定了生命周期阶段人员的职责和素质
          • 第 8 章规定了风险评估的方法
          • 第 9 章规定了系统安全要求规范以及功能安全、技术安全和应用条件安全的要求;
          • 第 10 章规定了分配功能安全完整性要求和实现
          • 第 11 章规定了框架和系统需求分配阶段，以及设计和实现阶段的安全性工作，包括因果分析、危险识别和共同原因分析。
          • 附录 A 提出了 ALAＲP、GAME、MEM 3 种风险接受准则
          • 附录 B 提出了如何根据故障和事故统计信息派生 THＲ
          • 附录 C 提出了 SIL 分配指南; 附录D 规定了安全目标分摊方法
          • 附录 E 给出了风险量化中的常见错误
          • 附录 F 给出了安全分析的技术和方法; 附录 G 规定了关键系统安全角色和责任。
        • GBT 21562
          • 轨道交通 可靠性、可用性、可维修性和安全性规范及示例
          • 第二部分：安全性的应用指南
          • 第三部分：机车车辆RAM的应用指南
    • EN50128
      • EN50128-2001（已废止）
      • EN50128-2011：Railway applications – Communication, signaling and processing systems – Software for railway control and protection systems 轨道交通——通信、信号、处理系统——控制和防护系统软件 ——GB/T 28808
        • 前言
        • 引言
          • 原则
          • 功能步骤
        • char
          • 一、 范围
          • 二、 规范性引用文件
          • 三、 术语和定义
          • 四、 目标和一致性
          • 五、 软件安全完整性等级
            • 目标
              • 定义软件的安全完整性等级的设置
          • 六、 人员和人员职责
          • 七、 生命周期和文档
            • 目标
              • 规划软件开发的阶段和活动
              • 记录贯穿整个软件生命周期的所有与软件相关的信息
            • 列了项目过程中涉及的相关文件
          • 八、 软件需求规范
            • 目标
              • 描述一个文档，为满足所有系统需求，该文档根据软件安全完整性等级规定了一整套的软件需求，它是对每个软件工程师均适用的综合性文档。
              • 用于描述软件需求测试规范
            • 输入 | 输出文档
          • 九、 软件结构
            • 目标
              • 导出软件结构，按照选定软件安全完整性等级的要求实现软件需求规范的需求
              • 评审系统结构对软件的需求
              • 确定和评价硬件/软件交互作用对安全性的重要性
              • 如果之前没有定义设计方法，那么选择一种设计方法
          • 十、 软件设计和实现
            • 目标
              • 设计和实现在软件需求规范和软件结构规范中既定软件安全完整性的软件
              • 获得可分析、可测试、可验证和可维护的软件。此阶段还包括模块测试，由于验证和测试在确认过程中起关键作用，所以在设计和开发的过程中应特殊考虑验证和测试要求，以确保从一开始就使用目标系统及其软件易于测试。
              • 在促进确认、验证、评估和维护的整个软件生命周期内，选择一套适合所要求的软件安全完整等级工具，包括语音和编辑器。
            • 要求
              • 10.4.4
                • 追溯到软件结构的软件组件及其安全完整性等级
              • 10.4.8
                • 只要适用，就应适用自动化测试工具和集成开发工具。
              • 10.4.9
                • 选定的软件安全完整性等级的要求，所选程序设计语言应具有翻译器/编辑器，且该应具备下述条件
              • 10.4.10
                • 所选语言应满足以下要求
              • 10.4.14
                • 软件模块测试要求
          • 十一、 软件验证和测试
            • 目标
              • 按照选定的软件安全完整性等级的要求，按本阶段提出的输入，测试并评价某一给定阶段的产品，以确保产品正确并与标准一致。
          • 十二、 软件/硬件集成
            • 目标
              • 证明软件和硬件间正确地交互作用，完成它们预定的功能
              • 组合软件与硬件并确保它们的相容性，以满足系统安全需求规范和设定的软件安全完整性等级的需求。
          • 十三、 软件确认
            • 目标
              • 分析和测试已集成系统，以确保其符合软件需求规范，并注重安全完整性等级对功能和安全性的特定要求。
          • 十四、 软件评估
            • 目标：评价生命周期过程和形成的产品，以判定软件是否达到设定的软件安全完整性等级，及能否在预期应用中适用。
            • 要求：评估员。。。
          • 十五、 软件质量保证
            • 目标
              • 确定、监控所有保证软件达到要求的质量需采取的技术和管理活动，为有效开展验证和确认活动，需提供针对系统性故障所需的定性防护并形成审核记录。
          • 十六、 软件维护
            • 目标
              • 确保软件要求执行，并在对软件自身作纠正，功能增强和修改时保持软件安全完整性等级和可信性
          • 十七、 基于应用数据配置的系统
            • 目标
              • 轨道交通控制和防护系统的一个显著特征是需要为满足特定应用的需求设计装置。由应用数据配置的系统允许使用“型式审批”过的通过软件，每个装置的特定需求应被定义成数据（专用数据），这数据一般采取列表信息形式或采用由通用软件解释的专用语言
            • 软件开发
              • 软件需求规范阶段：应确定每个系统和子系统中哪些功能将使用应用数据，分配给每个子系统的系统安全完整性等级将决定系统所有装置的数据后续开发的应用标准。
              • 软件设计阶段：应确定通用软件和应用数据之间的详细接口，除非这已在生命周期的早期阶段中得以规定，例如：要求使用现存的面向特定应用的语言的结果。
              • 软件模块设计阶段：程序源代码和数据之间应实行严格的分离，及除非对软件和数据之间的已规定接口做了变动，否则可在不修改另一部分（数据或软件）时就对通用软件或数据进行重新编译和修改。类似地，待定应用数据宜和其他数据分开。
              • 在软件维护阶段：修改控制规程应确保只有在确定被修改的通用软件和原数据相兼容或对数据已作必要的修订后，才能安全修改后的通用软件
              • 在软件验证过程和软件确认阶段。。。
              • 概要
                • 软件安全路线图
                • 开发生命周期1
                • 开发生命周期2
        • 附录A（规范性附录）技术和措施的选择和准则 —— char7~16的每个条款都有相关的条款表格来说明实现符合的方法
          • 表A.1 生命周期和文档（第7章）
          • 表A.1 软件需求规范（第8章）
          • 表A.3 软件结构（第9章）
          • 表A.4 软件设计和实施（第10章）
          • 表A.5 验证和测试（第11章）
          • 表A.6 软件/硬件集成（第12章）
          • 表A.7 软件确认（第13章）
          • 表A.8 需评估的条款
          • 表A.9 软件评估（第14章）的评估技术
          • 表A.10 软件质量保证
          • 表A.11 软件维护
          • 表A.12 第10章参考设计和编码标准
          • 表A.13 第11章和第14章参考的动态分析和测试
          • 表A.14 第10章、第12章、第13章和第14章参考的功能/黑箱测试
          • 表A.15 第10章 参考的程序语言
          • 表A.16 第13章 参考的建模（图）
          • 表A.17 第10章、第12章和第13章参考的性能测试
          • 表A.18 第8章和第10章参考的半形式化方法（图）
          • 表A.19 第11章和第14章参考的半形式化方法
          • 表A.20 第10章参考的模块化方法
        • 附录B（资料性附录）技术参考资料
          • 1||| 人工智能故障纠正
            • 目标：借助引入方法和过程模型的组合以及某种在线安全性和可靠性分析，以便能用一种很灵活的方式应答可能的危害
          • 2||| 可分析的程序
            • 目标：以一种便于程序分析的方法来设计程序。程序行为在基于分析基础上一定是安全可测试的。
          • 3||| 雪崩/过载测试
          • 4||| 边界值分析
          • 5||| 反向恢复
          • 6||| 因果图
          • 7||| 经认证的工具和经认证的翻译器
          • 8||| 检查表
          • 9||| 控制流分析
          • 10||| 共因失效分析
          • 11||| 数据流分析
          • 12||| 数据流图
          • 13||| 数据记录和分析
          • 14||| 判定表
          • 15||| 防御性编程
          • 16||| 设计和编码标准
          • 17||| 软件多样化
          • 18||| 动态再配置
          • 19||| 等价类和输入分区测试
          • 20||| 差错检测码和纠正码
          • 21||| 错误推测
          • 22||| 错误播种
          • 23||| 事件树分析
          • 24||| Fagan（菲根）检查法
          • 25||| 失效断言编程
          • 26||| SEEA——软件错误影响分析
          • 27||| 故障检测和诊断
          • 28||| 故障树分析
          • 29||| 有限状态机/状态转换图
          • 30||| 形式化方法
            • CCS——通信系统的计算
        • 附录NA（资料性附录）与规范性引用国际文件有关的我国文件
    • EN50129
      • EN50129-2018：Railway applications – Communication, signaling and processing systems – Safety related electronic systems for signalling 轨道交通——通信、信号、处理系统——信号用安全相关电子系统 ——GB/T 28809
        • 前言
        • 引言
        • char
          • 一、 范围
          • 二、 规范性引用文件
          • 三、 术语和缩略语
          • 四、 整体框架
          • 五、 安全验收和审批条件
            • 1. 安全论据
              • 1||| 质量管理证据
              • 2||| 安全管理证据
              • 3||| 功能安全和技术安全证据
              • 在下面的章节
            • 2. 质量管理证据
            • 3. 安全管理证据
              • 安全生命周期
              • 安全组织
              • 安全计划
              • 危害日志
              • 安全需求规范
              • 系统/子系统/设备的设计
              • 安全评审
              • 安全验证和确认
              • 安全举证
              • 系统/子系统/设备交付
              • 运行和维护
              • 系统停用和处置
            • 4. 功能安全和技术安全证据
            • 5. 安全验收和审批
        • 附录A（规范性附录）安全完整性等级
          • 概要
          • 安全需求
          • 安全完整性
          • 安全完整性需求的分配
            • 风险分析
              • 系统定义和危害识别
              • 后果分析、风险评估和容许危害率分配
            • 危害控制
              • 原因分析
              • 共因失效分析
                • 物理独立性
                • 功能独立性
                • 流程独立性
            • 对由设计引入的新危害的识别与处理
          • 安全完整性等级SIL
            • 概要
            • SIL与安全目标的关系
        • 附录B（规范性附录）技术需求
          • （1） 概要
          • （2） 功能正确运行的保障
          • （3） 故障的影响
          • （4） 外界影响下的运行
          • （5） 安全相关应用条件
          • （6） 安全合格测试
        • 附录C（规范性附录）硬件元器件失效模式的识别
          • （1） 概要
          • （2） 一般规程
          • （3） 针对集成电路的规程（包含微处理器）
          • （4） 带内在物理特征元器件的规程
          • （5） 元器件失效模式的通用说明
          • （6） 带有内在物理特征元器件的附加通用说明
          • （7） 带有内在物理特征的元器件的特别说明
        • 附录D（资料性附录）补充资料
          • 概要
          • 内部物理独立性的获得
            • 主要独立性
            • 次要独立性
          • 外部物理独立性的获得
          • 单一故障分析方法实例
          • 多重故障分析方法实例
        • 附录E =（资料性附录）安全相关电子信号系统避免系统性故障以及控制随机故障和系统性故障的技术和措施
          • 表1：安全计划和质量保证活动
          • 表2：系统需求规范
          • 表3：安全组织
          • 表4：系统/子系统/设备的结构
          • 表5：设计要点
          • 表6：失效和危害分析方法
          • 表7：系统/子系统/设备的设计和开发
          • 表8：设计阶段的文档
          • 表9：系统和产品设计的验证和确认
          • 表10：实时、运行和维护
        • 参考文献
        • 129规定的3种方式
          • 组合式
            • 采用组合式实现方式，每个安全相关功能应至少由两个项来执行。各项之间互相独立，避免共因失效，并且应该能检测出一个项中的危险故障并在足够的时间内加以拒绝，以避免第２个 项发生相同故障。组合式安全电路实现原理如图２所示。 组合式安全电路的本质是采用相异的冗余电路实现功能安全，消除电路单点故障。
          • 反应式
            • 采用反应式实现方式，这种技术允许一个安全功能由单个项执行，前提是通过快速的危险故障检测和拒绝来确保它的安全操作。虽 然只由一 个项来实施实际的安全功能，但检查／测试／检测功能应被看作第２项，并且两项之间相互独立，避免共因失效。反应式安全电路实现原理如图３所示。 反应式安全电路的本质是利用相异电路互相校验实现功能安全。
          • 固有式
            • 采用固有式实现方式，一个安全功能仅由单个项执行，且该项所有失效模式均为安全的。固有式安全电路实现原理如图４所示。固有式安全电路的本质是利用电路的独特性确保电路任何失效模式均导向安全，实现功能安全。
    • EN50657：铁路应用 机车车辆应用机车车辆上的软件-2017
  • IEC
    • IEC61508-2010系列标准： 《电气／电子／可编程电子安全相关系统的功能安全》 —— GB/T 20438
      • 1. 一般要求
        • 引言
        • 范围
        • 规范性引用文件
        • 定义和缩略语
        • 与GB/T20438的符合性
        • 文档
        • 功能安全管理
        • 整体安全生命周期的要求
          • 概述
          • 概念
          • 整体范围确定
          • 危险与风险分析
          • 整体安全要求
          • 整体安全要求分配
      • 2. 电气/电子/可编程电子安全相关系统的要求
      • 3. 软件要求
      • 4. 定义和缩略语
      • 5. 确定安全完整性等级的方法示例
      • 6. GB/T 20438.2和GB/T 20438.3的应用指南
      • 7. 技术和措施概述
• noun
  • RAMS
  • 定量
    • 失效率
  • 定性
    • 质量管理和安全管理以及技术安全条件等
  • 风险 RISK
    • 工业自动化的生产过程都或多或少的存在危险。工业设备（比如：一套液压系统、一套电气传动系统或一套气动控制系统）在运行过程中可能会发生故障而导致某些危险，这些危险可能会造成的伤害包括人的身体的损伤、健康状态的损害、财产的损失或者环境的破坏。 发生危险时可能会造成伤害，也可能不会造成伤害。当造成伤害时，有的情况下是一种轻度伤害，有的情况下是比较严重的伤害。我们把危险发生时，造成伤害的概率和伤害程度的组合，称为风险（Risk）。————https://zhuanlan.zhihu.com/p/452293478?utm_medium=social&utm_oi=1571785701376602112&utm_psn=1575625024437907456&utm_source=wechat_session
    • 可容忍风险：给定范围内的风险都是可以接收的
    • 安全：不可接收风险的状态
  • 功能安全（Functional Safety）
    • 整体安全中与受控设备和受控设备控制系统相关的部分，它取决于电气/电子/可编程电子安全相关系统和其他风险降低措施正确执行其功能。——https://zhuanlan.zhihu.com/p/452293478?utm_medium=social&utm_oi=1571785701376602112&utm_psn=1575625024437907456&utm_source=wechat_session （ 理解为一个相对整体的概念）
  • 安全功能（Safety Function）
    • 针对特定的危险事件，为实现或保持受控设备的安全状态，由电气/电子/可编程电子安全相关系统或其他风险降低措施实现的功能；安全功能包括①在要求时执行的功能，作为一种主动行为规避风险（比如主动关闭电机）；②采取预防行为的功能（比如防止电机误启动）； —— ——https://zhuanlan.zhihu.com/p/452293478?utm_medium=social&utm_oi=1571785701376602112&utm_psn=1575625024437907456&utm_source=wechat_session
  • 安全状态（Safe State）
    • 达到安全时受控设备的状态 —— https://zhuanlan.zhihu.com/p/452293478?utm_medium=social&utm_oi=1571785701376602112&utm_psn=1575625024437907456&utm_source=wechat_session
  • 安全相关系统（Safety-related System）
    • 是指能满足如下两项要求的系统：①执行要求的安全功能足以实现或保持受控设备的安全状态；②自身或与其他电气/电子/可编程电子安全相关系统、其他风险降低措施一起，能够实现要求的安全功能所需的安全完整性；——https://zhuanlan.zhihu.com/p/452293478?utm_medium=social&utm_oi=1571785701376602112&utm_psn=1575625024437907456&utm_source=wechat_session
  • 安全完整性（Safety Integrity）
    • 安全完整性（Safety Integrity）是指在规定的时间段内和规定的条件下，"安全相关系统成功"执行规定的安全功能的概率。安全完整性由硬件安全完整性和系统性安全完整性构成。安全完整性越高，安全相关系统在要求时执行规定的安全功能或实现规定的状态的概率就越高。 在确定安全完整性时应包括所有导致非安全状态的失效原因，比如：硬件失效、 软件导致的失效和电磁干扰导致的失效。某些类型的失效，尤其是随机硬件失效，可以用危险失效模式下的平均失效频率或安全相关保护系统未能在要求时动作的概率来量化。但是安全完整性还取决于许多不能精确量化的、只可定性考虑的因素。 （提到就是说：这个安全功能概率） ——https://zhuanlan.zhihu.com/p/452293478?utm_medium=social&utm_oi=1571785701376602112&utm_psn=1575625024437907456&utm_source=wechat_session
    • 安全完整性等级（Safety Integrity Level，SIL）：对安全完整性的量化。
      • 在低要求运行模式的安全功能目标失效量和高要求 连续运行模式下的安全功能目标失效量  ——https://zhuanlan.zhihu.com/p/452293478?utm_medium=social&utm_oi=1571785701376602112&utm_psn=1575625024437907456&utm_source=wechat_session
  • THR（Tolerable Hazard Rate）可容忍的危险率
    • 对于铁路运营方或铁路主管部门（railway duty holder）可承受的危害发生的概率，THR与危害发生后导致事故的严重度相关。——https://zhuanlan.zhihu.com/p/366210825?utm_medium=social&utm_oi=1571785701376602112&utm_psn=1575625540546789376&utm_source=wechat_session
  • TFFR（Tolerable Functional Failure Rate）可容忍的功能失效率
    • 可承受的系统功能导向危险失效的概率。当危害THR使用系统的功能进行防护时，对应的功能失效概率称之为TFFR。——https://zhuanlan.zhihu.com/p/366210825?utm_medium=social&utm_oi=1571785701376602112&utm_psn=1575625540546789376&utm_source=wechat_session
  • THR是对运营商或部门而言的。 TFFR是对供应商做的“功能”而言。 ——————— 结合两个，TFFR是THR的子类，TFFR针对于功能。
• sum
  • 安全完整性 —————————————————————— 指在规定的所有条件下，在规定的工作环境和持续时间内，一个安全相关系统达到的所有要求的安全功能的能力。安全完整性与安全相关系统达到要求的安全功能的能力有关，安全完整性要求越高，其无法执行要求的安全功能的几率就越低。
    • 实现 | 包含部分 | 满足要素 —————— 目的是降低
      • 结果导向：风险分析 | 安全分析： ———————————————— 对功能安全完整性进行划分功能模块，功能模块继续划分子部件或子模块，计算子部件或模块所要承担的安全风险，这里使用一个量化指标失效率。
      • 硬件安全完整性（hardware safety integrity） —————————— 属于：随机安全完整性 —— "定量"量化 ———————————— 1. 表征系统失效 2. 系统失效是由于系统寿命周期活动中的误差导致的
        • 量化指标 ———————— 安全相关产品的硬件从结构功能上来划分,又是由各子系统构成的。
          • 硬件故障裕度(HFT) (针对子系统)
          • 安全失效分数(safe failure fraction, SFF)(针对子系统)
          • 危险失效概率(PFDavg/PFH)(针对每个安全功能)
        • 从V模型的角度，展开安全产品系统以及硬件的方面的要求。包括安全需求规范、测试、架构设计、故障安全原则、常见诊断措施、降额设计、FMECA、RAM预计、PFH的计算等内容。
      • 系统安全完整性（systematic safety integrity） —————————— 属于：系统安全完整性 —— "定性"量化 —————————— 1. 表征随机失效 2. 随机失效是由统计分布描述的原因造成的这会导致产品、系统或流程在特定的组合或特定的条件下失效。
        • 定性 - 指标
          • 由于无法对系统失效进行量化，因此安全完整性等级被用作匹配定性方法和定量方法的手段。 由此引入了THR概念，它是Tolerable Hazard的缩写，表示可容忍的危害发生的概率。THR的SIL的对应关系通过表１来确定。
        • 硬件系统安全完整性
          • 系统架构设计 —————————— 针对实现不同的安全完整性等级，对功能失效率的要求不同。
          • 项目-过程管理 | 生命周期
            • 需求规范
            • 设计和开发
            • 集成
            • 运行和维护
            • 确认
            • 输出对应文件
        • 软件系统安全完整性
          • 从V模型的角度，详细展开安全软件开发需要执行的活动、技术方法和文档要求。
      • 从系统失效和随机失效的角度说区别： 随机失效通常归因于可以被统计监控的事件，从而可以估算其发生的概率；系统失效通常归因于统计数据无效的事件，因此通常无法估计其发生的概率。
    • 是风险评估的结果
• 参考文献