STPA（Systems-Theoretic Process Analysis）是一种系统理论过程分析方法，STPA于2005年由工程师Nancy G. Leveson开发，旨在帮助识别和分析系统中的潜在故障和安全风险。由于自动驾驶领域的逐步发展，系统复杂度逐渐增加，因此在ISO 21448（第6章/第7章）中也引入了STPA。
STPA 步骤 1 ：定义分析的目的和范围
定义分析目的分为四 部分：
定义分析目的概览
a) 定义损失
定义：损失涉及对利益相关者具有价值的东西。损失可能包括失去生命或人身 伤害、财产损失、环境污染、任务失败、声誉受损、敏感信息丢失或泄露或利益相关者无法接受的其他损失。
b) 识别系统级危险
定义：危险指的是一种系统状态或是一系列条件，在特定的最不利环境条件下，会导致事故（损失）
定义：系统是能够共同作用以达成某种共同目的、目标或状态的一系列组件。 系统可能包含子系统，也可能本身就是更加庞大系统的一个部分。
定义系统级危险有三个基本标准：
- 危险指的是系统状态或条件（而不是组件级的原因或环境状态）
- 危险会在一些最坏情况下导致损失
- 危险必须描述出需要预防的状态或状况
系统与系统边界、环境的关系
c) 识别系统级危险时的常见错误
混淆危险与危险原因
需检查每项危险是否包含以下信息：
<危险说明> = <系统> & <不安全条件> & <导致的损失>
例：H-1: 飞机在飞行过程中违反最低间隔标准 [L-1, L-2,
在评审危险时应评审哪些内容？
d) 定义系统级约束
定义：系统级约束规定了需要满足以预防危险（最终防止损失）的系统条件或行为。
一旦识别了系统级危险，需直接识别必须强制实施的系统级约束：只需简单地反转条件。
<危险> = <系统> & <不安全条件> & <导致的损失>
<安全约束> = <系统> & <执行条件> & <与危险的关系>
H-1:飞机违反最低间隔标准 [L-1, L-2, L-4, L-5]
SC-1:飞机必须满足与其他飞机及物体的最低间隔标准 [H-1]
e) 提炼系统级危险（可选）
STPA 步骤 2 ：控制结构的建模
a) 何为控制结构？
定义：分层控制结构指的是由反馈控制回路组成的系统模型。有效的控制结构 可以将约束施加到整个系统的行为上。
c) 构建控制结构
控制结构建模一般起始于抽象控制结构并反复添加细节。在很多情况下，系统 内的控制结构与控制回路可能较为明显或可从以往应用中进行再利用。
在评审控制结构时应评审哪些内容？ 以下建议有助于查找控制结构内的常见错误：
通过分析系统和功能规范来识别系统的控制层次体系及其接口环境，这被称为“控制结构”。提取控制器命令（也被称为“控制行为”）和来自受控过程与环境的反馈来进行分析。
高速领航驾驶的控制结构示例如图所示。
高速领航驾驶的高层面控制结构
STPA步骤 3 ：识别不安全的控制行为
定义：不安全控制行为（UCA）指的是在特定情境及最坏环境下可能导致危险的控制行为。
识别不安全控制行为
出现以下四种情况，代表控制行为可能存在安全隐患（以上面栏目中的内容给 出）
1. 未提供控制行为导致危险。
2. 提供控制行为后导致危险。
3. 提供可能安全的控制行为但提供节点过早、过晚或顺序错误
4. 控制行为持续太久或停止过早（仅针对持续性控制行为而非离散行为）。
每个不安全控制行为都包含五个部分：
UCA-2：BSCU Autobrake 在正常起飞时 提供 刹车命令 [H-4.3]
<来源> <情境> <类型> <控制行为> <相关危险>
第一部分是可以提供控制行为的控制器。第二部分是上面讨论到的情境。第三 部分是不安全控制行为的类型（提供、未提供、过早或过晚、停止太早或持续太久）。 第四部分是控制行为或命令本身（来自控制结构），最后一部分关联所可能导致的 危险（或子危险）。
不安全控制行为通常情况下按照上述顺序进行描述，但在某些情况下调换顺序 可以显得更加清晰自然。顺序无关紧要。重要的是每个不安全控制行为都要包含这 四个部分
以下为识别不安全控制行为时避免常见错误的建议：
控制行为分析概览：
举例：
给定 UCA，可以定义控制器安全约束，以确保防止 UCA。控制器安全约束指定控制器行为的断言或不变式，需要满足这些断言或不变式以防止发生 UCA。
STPA 步骤4：识别原因场景
定义：致因场景描述的是可能导致不安全控制行为以及危险的诱发因素。
识别致因场景
必须考虑的两种情境：
a) 识别导致不安全控制行为的致因场景
可导致不安全控制行为的致因 场景包括：
致因场景识别概览：
识别会导致当前不安全控制行为的系统控制器自身要素或其他要素的一个或多个输出不足的组合，是这个分析的第一步。作为下一步，确定导致已确定的不足条件的因果因素。这些可能是输出不足，功能不足和触发条件。
识别控制措施和缓解措施，改进系统设计并导出要求
完成本文件中的STPA核心活动后，STPA的剩余活动可分配给相应的流程步骤，对于解决SOTIF相关风险的功能修改见第8章，相应的，如果是失效相关的原因，见GB/T 34590.4-XXXX，第六章。这涉及制定适合满足 STPA 安全约束的可实施要求。
STPA 输出与追溯过程
STPA 输出间的追溯过程
这些STPA 输出用处多样，包括：
- 导出系统架构
- 生成可执行要求
- 识别设计建议
- 识别所需的缓和与保护措施
- 定义测试案例并生成测试计划
- 导出新的设计决策（如果STPA 用于发展阶段）
- 评估现有设计决策并识别差距与所需变更（如果STPA 用于设计完成后期）
- 生成领先风险指标
- 设计更加有效的安全管理系统
- 等
参考文件：
链接：http://psas.scripts.mit.edu/home/get_file3.php?name=STPA_handbook_chinese.pdf