MUNIK解读ISO26262-异常管理
点击上方蓝字关注我们
摘要
异常在标准中的定义是在进行功能安全开发过程中会偏离预期并可能导致伤害的情况，如果发生异常，将会影响功能安全目标和需求，属于比较严重的问题，因此在整个开发过程中，需要对功能安全异常进行监督和管理。在标准中也对此有要求建立一套完整的流程文件来进行管控，便于我们在过程中可以及时发现异常，并上报和解决。
接下来将要从三方面对异常管理进行展开：
MUNIK
1
什么是功能安全异常？
MUNIK
Tech
从上文中关于标准对异常的定义可以得出，异常是存在导致伤害出现的情况，这些情况通常体现为功能安全过程中的交付物或者安全活动违背功能安全目标或者功能安全需求。例如，标准中要求对于安全生命周期的每个阶段及子阶段，应实施验证活动，但如果有的活动并未实施验证活动，那么最终的交付物会不符合功能安全的要求；或者实际执行的功能安全需求ASIL等级与最初定义的ASIL等级不符，也是一种异常。
异常通常会出现在内部评审，各分析和测试活动，DIA环节，也可能出现在功能安全审核，评估，生产阶段。组织可以对设计和生产等不同阶段的异常情况制定不同的流程来定义，也可以采取通用的处理流程。
2
功能安全异常参与者一般有哪些？
MUNIK
Tech
图：异常管理步骤
异常管理主要分为上图中四个环节，对于流程的详细内容可参考第三章的描述。其主要参与者信息如下：
异常发起者：鼓励项目实施的所有参与人员都可以发起异常，责任人可以是各团队负责人（如硬件开发团队、软件开发团队等）。发起者负责收集异常信息，并记录异常的相关信息，如发起人的信息（如部门，姓名）、异常发现的阶段和日期，异常的具体描述等，并将信息进行上报至管理人员；
异常分析者在收到发起者报告的异常情况后，分析其是否与功能安全相关。
分析后，则需要实施异常的解决方法。负责制定措施的团队或人员，可以是分析者和评估者一起，如设计人员，测试人员，安全经理，项目经理，安全专家等。
异常记录者：当异常关闭后，则需要确认异常状态并将过程进行记录。
整体流程的管理工作由功能安全经理或功能安全项目经理负责，哪些产物或者活动出现了异常，就由相对应的负责人进行分析，评估和解决。
3
功能安全异常如何执行？
MUNIK
Tech
图：质量异常处理流程
在质量体系中的异常管理流程，通常为：相关人员检测到异常后及时记录并上报给质量部门，对于出现异常的产品进行停机或停产，追溯已制品是否存在同样的问题，如果有则需要进行扣留，同时品质部门也会对异常品进行原因的分析，便于制定合适的解决方案，再到通知对应的责任单位进行改进（如调整工艺、修复等方案）。当异常品的方案实施完毕后，需要对其进行验证，如果通过，则异常关闭，可以继续生产，如果未通过，则需要重新进行分析和改进措施制定。
区别于常规项目中异常管理流程，我们在进行功能安全开发时，更应关注功能安全特有的一些方面。异常管理流程大致分为以下内容：
图：功能安全异常管理流程
识别异常：
异常发起者对识别到的异常相关信息进行记录和上报。建议各阶段发现的异常首先应该上报给对应的责任人，在负责人能力范围内若无法给出明确判断，再考虑上升到项目安全经理或公司层面安全经理进行解决。
异常分析：
首先需要分析异常是否会影响功能安全目标：
若与功能安全相关的异常，还可以分析异常的具体影响：如异常的辐射范围，会影响哪些工作成果，造成什么影响，异常解决的优先级如何，并进行详细描述，通过对这些方面的考虑，可以帮助我们对发现的异常有了更全面的了解，便于我们调配最合适的资源去解决异常。
若与功能安全不相关，且有充足的证据证明此项异常不会构成不合理的风险，可进行关闭。
需要注意的是，评估活动应考虑分析团队与后续判定实施结果的团队的独立性，以保证评估结果的客观性，比如分析环节是硬件开发团队负责人给出的结果，后者便可以是项目安全经理主导，项目经理，硬件开发他团队成员参与，若在项目层面无法给出评估结论，可升级到公司层面。
异常的解决和管理：
根据分析结果制定对应的解决措施，若分析结果显示需要采取变更，则应该按照标准Part 8的变更管理流程执行对应活动（关于变更管理可参考本公众号文章《功能安全之变更管理》），异常的解决如果在开发阶段，技术变更是其中的一种方式。如前文中所说，异常并不会只出现在开发阶段，也会体现在其他方面，因此，过程中同样需要组织对异常进行管理，才能让整个活动有序进行。
关于异常的管理，需要组织建立、执行和维护异常管理流程。比如前文中提到的异常管理需要哪些人员进行参与；对于不同的异常根据不同的优先级依次解决；在异常解决时的沟通机制，比如当开发人员完成异常的解决措施后，需要通知相应的测试人员对结果进行判定，确认异常已解决并达到了预期的效果，那么同时需要通知涉及到此项异常的人员知悉。
结果的判定：
对于实施异常解决措施后的结果，需要判断其是否达到了预期的结果，如不符合，对于不满足的内容需要重新制定措施进行异常的解决并按照相关的流程管理文件进行执行，如果满足，便可以将此条异常进行关闭。
异常的关闭：
关于异常关闭，总结来说体现为两种条件：
a)当异常情况通过分析和评估后，被识别安全异常。并且制定的解决措施结果通过了相关的验证，结果显示达到了预期，则异常关闭。
b)当异常情况通过分析和评估后，在合理的理由和充足的证据支撑下，显示此即便是发生也不会导致不合理危害的出现，则异常关闭。
（注：如果项目层面制定的措施未解决异常情况，应将问题升级到公司层面，由安全经理以及安全专家引入更多资源处理异常。）
当实施异常解决措施后达到了异常关闭的条件，确认关闭状态并将过程记录归档即可，由此，整个异常管理活动结束。
这样描述会有些抽象，举个例子来说就是比如某个设计人员发现了一个异常（在进行硬件安全分析过程中，发现有遗留单点故障需要增加新的安全机制覆盖），首先将异常上报给负责人，详细说明异常的情况（具体是哪个需求或者部件需要增加安全机制），再对该异常进行分析后得出其与功能安全相关的结论，相应的解决措施是进行技术变更，参照组织制定的相关流程执行解决措施（如针对XX设计规范进行了技术变更），实施后达到了预期的效果，便可以将这条异常关闭，同时对于整个过程进行记录。
组织在执行功能安全项目开发时，如果前期通过在整个生命周期管控每一条发现的异常情况，并且在制定安全文化的时候也考虑制定一定措施，来鼓励大家积极发现异常，并上报，解决异常，那么在降低可能会导致危害的情况出现的同时，在后续开发过程中也可以对此进行规避，优化开发流程，丰富功能安全开发经验。
——原创文章，转载请授权并注明出处，否则必究。
