本篇属于预期功能安全SOTIF专题系列第03篇内容，我们一起聊聊预期功能安全ISO 21448中如何采用STPA进行危害分析。
阅读之前强烈建议参考之前系列文章:
上篇文章我们聊到了ISO 21448 SOTIF工作流程，前两部分内容，即规范定义和设计，及危害分析和风险评估，和功能安全ISO 26262对应内容基本一致，只是研究对象和方法适用程度有所区别。
在规范定义和设计中，需要定义所研究的自动驾驶系统的组成(系统及其要素)、功能和性能局限性(例如，分类不足，测量不足，运动学估算不足，假阳/阴性探测等)的充分理解，最终会形成一份已知的功能不足、相关的触发条件及其应对措施(如果已经存在或定义)的详尽列表，以便执行后续阶段的活动。整体内容比较容易理解，在此不再赘述。
根据规范定义和设计，则需要对预期功能不足、或由可合理预见的人员误用所导致的危害和风险进行识别，即危害分析和风险评估。
考虑到预期功能安全SOTIF研究对象的复杂性，即高级辅助或自动驾驶系统，在危害分析中，除ISO 26262中常用的HAZOP， FMEA，FTA等安全分析手段外，STPA(System-Theoretic Process Analysis)，即系统理论过程分析，可能更适合于SOTIF危害分析。
为此，本文主要阐述以下关于STPA的问题：
SOTIF危害分析
系统理论过程分析STPA
STPA与FMEA，FTA区别
01
SOTIF危害分析
针对危害分析的方法，ISO26262中推荐的安全分析方法，包括归纳分析方法(例如FMEA)，演绎分析方法(例如FTA)，同样适用于预期功能安全危害分析过程。只是考虑到自动驾驶系统功能的复杂性和特殊性，除上述传统的安全分析方法外，系统理论过程分析(STPA)在预期功能安全危害分析中可能更为适用。
STPA是一种安全分析方法，用于评估复杂系统的安全和识别安全约束及要求，STPA对SOTIF的用途主要在于可以相对较好地解决功能不足、系统在不适用的环境中使用、人员误用等问题。
02
系统理论过程分析(STPA)
STPA步骤1：定义分析的目的和范围
该步骤的目的在于，识别出研究对象对利益相关者可能造成的损失(Loss)和整车层面的危害(Hazard)，这部分内容和ISO 26262中概念开发阶段的危害分析过程基本一致。
所谓的损失(Loss)，本质上和伤害等效，主要包括以下两个方面:
─ 对物的伤害: 包括车辆或外部物体的损伤
对于自动驾驶系统，乃至整个车辆而言，损失无非就这两个方面，相对比较固定。
所谓的整车层面的危害(Hazard)，就是整车层面的状态或条件，和特定的恶劣环境相结合，导致事故或损失的产生，这个定义和ISO 26262一致，即危害导致损失(伤害)的潜在来源。
整车危害的导出可以利用ISO 26262 危害分析中HAZOP方法，根据自动或辅助驾驶系统功能，例如，对于辅助驾驶车道保持系统LKA，借助HAZOP引导词导出潜在的危害示例如下:
该步骤和ISO 26262危害分析基本一致，只是导致危害产生的来源不同而已，功能安全危害源于电子电气系统的系统性失效或随机硬件失效，而预期功能安全SOTIF源于由功能和性能局限，或人为合理误触发。
STPA步骤2：控制结构的建模
从控制结构出发，进行安全分析，识别出整车危害(Hazard)产生的原因，是STPA分析的核心，所以控制模型的建立是STPA分析的基础。
所谓的控制结构或模型是系统控制行为和反馈行为的集合，用于展示系统内部决策逻辑和过程。
这里的控制结构不是ISO 26262中相关项定义中系统的组成及结构的描述，而是从系统的控制器控制逻辑出发，阐述为了使得对控制对象实现特定的功能，需要采用哪些控制模块，它们之间的层次，相互作用关系等。
如下图所示，对于控制系统而言，涉及的对象一般包括传感器(输入)，操作者，控制器以及执行器(输出)，本质上操作者也属于传感器，只是为了更好地体现人对系统的影响，尤其是SOTIF人为合理误触发，将操作者单独罗列。控制结构的作用就是描述它们之间的控制，反馈行为。
STPA步骤3：识别不安全的控制行为
基于步骤2中控制结构模型，就可以通过控制行为分析引导词，对控制结构中每个控制器(包括人类)的控制行为进行安全分析，识别出可能会导致步骤1中定义的整车危害(Hazard)产生的不安全的控制行为(UCA, Unsafe Controll Action)。
STPA常见的控制行为引导词包括:
─ 未提供或不遵守安全所要求的控制
─ 提供不安全的控制从而导致危险
─ 所提供的潜在安全控制太晚、过早，或无序
─ 控制结束太快或应用时间过长
这里的STPA控制行为引导词和HAZOP引导词基本上类似，只是HAZOP引导词针对功能，包括功能的丧失，提供非预期的功能等，而STPA引导词针对控制行为，需要和整车危害(Hazard)挂钩。
STPA步骤4：识别原因场景
它属于STPA核心步骤，确定导致危害的原因场景和相应的因果因素，主要是识别导致不安全控制行为产生的可能诱发原因，也是ISO 21448中第7章，即潜在功能不足与触发条件识别主要内容，主要是回答以下两个问题:
问题一: 为什么控制行为(CA)没有或没有被正确地执行? 相关故障场景是什么？
继续以LKA为例:
─ 由于以下信息错误，控制器错误地认为不会发生车道的偏离，例如，车道线，方向盘转角等
问题二: 为什么会产生这样的不安全控制行为(UCA)？
例如:
─ 车道偏移被LKA错误计算
上述两个问题属于递进关系，a)属于过程，情景分析，b)基于a)的分析结果识别最终原因，可以以此制定新的安全措施作为安全需求，为后续改进提供基础。
STPA步骤5：识别控制措施和缓解措施并改进
03
STPA与FMEA，FTA区别
个人认为主要区别如下：
1
一般的安全分析方法，不管是FMEA，还是FTA，都是基于失效链的分析逻辑，认为事故是由独立的组件的失效或其组合导致的。
但随着系统复杂度不断增加，系统或组件间的交互越发复杂，事故的发生不再是源于某个特定的组件，更多的是它们之间不安全的交互或多重因素共同影响，而本质上，复杂系统组件本身及其交互都是为了确定系统的控制行为，只要控制行为安全，理论上就不会产生事故，所以STPA认为事故属于控制不当的问题。
2
而STPA分析的基础是系统控制结构，是系统设计必不可少的环节，一旦控制结构明确，分析过程相对简单，相比而言，对分析人员的经验依赖较小。
3
在一定程度上，STPA结合了FMEA和FTA自下而上和自上而下的分析过程，首先通过HAZOP或简化的FMEA这种自下而上的分析过程，定义系统损失和整车危害，然后，根据系统控制结构，自上而下，识别不安全控制行为，分析其发生的原因。
写在最后:
END
【点赞】和【在看】= 原创的动力
多谢【点赞】和【在看】
[1] Mahajan, Haneet Singh, Thomas Bradley, and Sudeep Pasricha. "Application of systems theoretic process analysis to a lane keeping assist system." Reliability Engineering & System Safety 167 (2017): 177-183.
