系统工程手册（Systems Engineering Handbook）是国际系统工程协会（INCOSE）编著的一本权威性指导书籍，旨在为系统工程的全生命周期过程和活动提供详细的指南，其内容基本涵盖ISO/IEC/IEEE 15288（系统生命周期过程）和ISO/IEC/IEEE 26771（系统工程管理计划）。这些标准为系统工程的全生命周期提供了清晰的指导，涵盖了需求分析、设计、开发、测试和维护等环节，帮助工程师高效管理复杂项目，确保系统从概念到退役的全过程都能科学运作。
为了方便感兴趣的人士参考，reddish(@srs.pub)基于系统工程手册第四版（2015），借助通义完成翻译，并做校稿，个别地方有做必要的修正和裁剪。
本文是的中文译本的第十章专业工程活动(Specialty Enginerring Activities)的第十小节：系统安全工程(System Safety Engineering)。
又注：本文是Safety系统安全工程，另有security的系统安全，参加本站的其他文章https://srs.pub/specification/system-security-engineering.html。 security 和safety的区分，参见reddish(@srs.pub)的文章https://srs.pub/thinking/safety-security.htm ***
1 系统安全工程
系统安全工程是系统工程的一个应用衍生，它基于良好的系统思维基础，并在系统的每个生命周期阶段进行分析应用。系统安全工程的核心是对每个需求、每个系统元素以及在正在开发、操作或维持的系统背景下的每个宏观到微观行为进行分析，以识别和消除或控制安全风险潜力。安全风险潜力被定义为任何可能导致系统产生不良状态，从而导致系统损坏、伤害参与系统操作和维护的人员，或对环境造成损害的条件。
系统安全工程的主要目标是通过与安全相关的要求影响设计，以确保系统的开发、生产、利用、支持和退役阶段的安全。安全系统的益处众多，包括但不限于降低与成本、进度、操作有效性、系统可用性和法律责任相关的风险。
2 SE在系统安全中的作用
随着当今系统的规模和复杂性增加，所使用的系统工程方法变得更为关键。系统级别的属性，如安全性 1，必须在设计这些系统时就考虑进去。它们不能在事后添加并期望是安全的。系统的设计是为了实现特定的目标以满足要求和约束。
系统工程必须开发一种方法来组织工程设计过程，以确保系统安全的目标被包含在内。系统工程必须从一开始就将系统安全工程融入其工程流程，以便在进行工程设计决策时能够将安全性设计到系统中。
关于系统安全工程，系统工程确定系统的目标，并参与识别和记录需要避免的潜在危害。根据这些信息，可以识别并记录一套系统功能需求、安全需求和约束条件。这些需求将为系统的设计和操作奠定基础，以确保将安全性设计到系统中。系统工程必须从早期概念阶段建立系统安全工程，并在整个系统生命周期中持续这一过程。系统工程应确保设计决策受到安全考虑的指导，同时考虑到系统需求和约束条件。
3 识别并整合系统安全要求
系统安全工程师审查并确定适用于联邦、军事、国家和行业法规、规范、标准和其他文件的“最佳实践”系统安全设计要求和指南，以设计和开发系统（例如，联邦机动车安全标准(FMVSS)、军事标准（MIL - STDs）、国家电气规范（NEC）和化学品注册、评估、授权和限制（REACH））。
这些初始要求用于推导出额外的系统安全设计要求，这些要求提供给设计工程师以消除或减少危险风险到可接受的水平。这些要求被整合到高级系统要求和设计文件中。然后，系统安全要求与系统中识别的危险相关联。
系统安全工程与SE一起确保系统安全设计要求和指南得到开发、完善、完整且正确地指定，并适当地转化为系统元素要求，以确保它们在系统硬件、软件和用户界面的设计和开发中得到实施。此外，还确定了适用的安全要求，以便将其纳入操作员、用户和诊断手册中的程序、流程、警告和注意事项中。
4 识别、分析和分类危害
在系统安全工程领域，有许多分析方法、技术和产品被认为是最佳实践和行业可接受的。例如，SAE International在SAE ARP 4754和4761中定义了特定的方法，这些方法通常在航空业中使用。美国国防部MIL - STD - 882也定义了特定的分析技术，这些技术在国防领域非常有用（DoD，2010b）。
无论使用何种标准或指导，以下非详尽的分析技术和安全工程工件列表反映了SE的最佳实践：
- 初步危险分析（PHA）
- 功能危害分析（FHA）
- 系统元素危害分析（SEHA）
- 系统危害分析(SHA)
- 运营和支持危害分析（O&SHA）
- 健康危害分析（HHA）
- 自由贸易协定
- 概率风险评估（PRA）
- 事件树分析（ETA）
系统安全工程师在系统概念定义的开始阶段就开始识别危险。危险分析的目的是识别潜在的危险及其可能存在于所考虑概念中的事故隐患。系统安全工程师从类似系统的安全经验中汲取教训，包括事故/事件危险跟踪记录、安全经验教训 2和设计指南，以制定这份清单。随着系统在开发周期中逐渐成熟，危险分析将得到更新，以识别和分析因设计变更而产生的新危险。
对每个识别出的危险进行深入的因果分析。该分析确定了所有可能导致危险发生的硬件、软件以及任何/所有控制实体（包括人类操作员）的贡献。每个因果因素的识别使系统安全工程师和系统工程师能够识别减轻危险并降低风险至可接受水平所需的特定系统安全要求/约束。
每个危险都被分析以确定其严重性和发生概率。危险的严重性和概率决定了其风险分类。MIL - STD - 882E的表A.I显示了事故严重性类别的示例（DoD，2010b），而表A.II显示了事故概率水平。事故风险分类是通过使用事故风险评估矩阵来执行的。这个矩阵用于对危险的事故风险潜力进行排名。MIL - STD - 882E的表A.III显示了事故风险评估矩阵的示例（DoD，2010b）。这个矩阵用于优先考虑减轻系统危险的工程努力。
与软件相关的危害不能仅仅依赖于MIL - STD - 882E(DoD, 2010b)表A.II中确定的危害概率。软件故障的分类通常由其危害严重程度以及软件功能对硬件的指挥、控制和自主程度决定。软件控制类别包括：（i）自主控制，（ii）软件行使控制或显示信息，允许独立安全系统或操作员进行干预的时间，（iii）软件发出命令或生成信息，需要操作员采取行动完成控制，以及（iv）软件不控制安全关键硬件或提供安全关键信息。然后使用严重性类别和控制类别建立软件关键性指数。这个矩阵可以用来优先考虑分配给设计、代码和测试的严谨水平(LOR)。安全关键软件是按照特定的LOR开发的，以确保软件能够按预期功能运行，并且不会执行意外的功能。
危害被优先排序，以便纠正措施可以首先集中在最严重的危害上。系统安全工作的目标是与工程设计合作，设计出没有危害的系统。由于完全无危害的设计是不可能或不切实际的，因此努力的重点是开发一个系统设计，其中没有具有不可接受的事故风险的危害。每个识别出的危害都会进行分析，以确定需要纳入设计中的要求，以将与危害相关的风险降低到可接受的水平。系统安全优先顺序用于定义实施系统安全要求以减少事故风险的顺序。优先顺序如下：
- 通过设计选择消除危害。
- 通过设计更改降低风险。
- 安装安全装置。
- 提供警告装置。
- 制定程序和培训。
最佳实践规定，一个功能的失效或错误操作将直接导致灾难性（死亡、永久性完全残疾、不可逆的重大环境影响或经济损失等于或超过1000万美元）或关键性（至少三名人员住院、可逆的重大环境影响或经济损失等于或超过100万美元但少于1000万美元）事故。严重性不能仅通过程序缓解措施来减轻。
危害分析活动的结果被记录在一个危害跟踪系统（HTS）中。HTS用于通过记录安全要求的实施、验证结果和剩余事故风险来跟踪每个危害。在整个系统的生命周期中，HTS都会进行更新。
5 验证和确认系统安全要求
系统安全工程师与系统工程师一起，为所有测试、演示、模型和检查提供输入，以验证系统是否符合已识别的系统安全要求。这样做是为了确保设计的安全性对于所有未通过设计消除的危害得到充分证明。系统安全工程师通常会见证那些被归类为灾难性和关键性的危害的验证/确认活动。所有用于验证/确认系统安全要求的测试活动的结果由系统安全工程师进行审查，并记录在HTS以及硬件或软件的测试和评估报告中。
6 评估安全风险
系统安全工程师在每个关键里程碑（初步设计审查、关键设计审查、项目完成等）以及关键测试或操作活动之前，对所承担的事故风险进行全面评估并记录。安全评估确定了硬件、软件和系统设计的所有安全特性。它还识别了在每个里程碑、测试或操作活动中可能存在于系统中的程序、硬件和软件相关危险。对于仍然存在于系统中的这些危险，确定了具体的程序控制和预防措施。
安全评估还识别并记录了在系统的设计、操作或维护中使用的危险材料，以及由系统产生的危险材料。同时，评估并记录了为什么不能使用非危险或低危险材料的原因。
7 总结
作为系统工程的一个组成部分，系统安全工程着重确保设计工程师在开发、生产、利用、支持和退役阶段获得一套完整的与安全相关的要求，以最大限度地降低系统的安全风险。最终目标是部署、操作和维护一个具有可接受安全风险的系统。理想的目标是实现无事故。