ISO26262初窥门径

这注定是个非常大且专业的主题，我没有吃透也就没法讲透，而且已经有很多权威的书籍论文进行过系统的阐释，所以我的写作目标在于以尽可能通俗的语言，让从业但非专业功能安全人员有基本的逻辑和概念的认识，达到与从业人员可以沟通的水平。

功能安全是一个通用性的概念，但在汽车行业E/E系统衍生为ISO26262，第一版为2011年，2018年释放了第二版，但由于两版之间没有本质差异，最主要的是我能查阅到的2018版的资料比较少，所以先按照2011版本来学习。

随着技术的复杂性，软件内容的增加，增加了发生系统性失效和随机硬件失效的可能性，这是ISO26262产生的原因，其核心就是通过增加安全机制（流程 技术）使得系统的风险降低到可接受程度，但它对具体E/E系统的功能性性能标准没有要求，不能定义或提升系统本身的性能，比如输出信号的精度，气囊的点火时间等。而是制定了特定的ASIL等级，QM和ABCD。

ISO26262共分10个部分，除了第1部分的术语外，分别针对流程、产品和工具（方法 论）三部分，流程更多是针对与人有关的可避免的系统性失效，而产品更多的是针对不可避免的随机硬件失效。其中的第2和第8部分对应流程，这两部分很像传统的质量管理体系，比如9001、16949或者ASPICE，而34567部分是关注产品的设计对错的，分别是概念阶段、产品研发阶段（系统、硬件、软件）和生产与操作，当然具体的流程仍然是融合在这几个章节的。第9部分是分析工具，一般主要是FMEA和FTA。第10部分呢，主要是一个标准执行的指导手册。

总结一下功能安全的简单流程。

首先是相关性定义（Item Definition），基于产品定义进行HARA（Hazard Analysis and Risk Assessment）分析，然后可以确定出来安全目标Safety Goal（含ASIL，SS，FTTI等），针对SG会进行进一步细化为功能安全需求FSR（Functional Safety Requirement），接着针对FSR做一个粗略设计，即PA（Preliminary Architecture），而FSR和PA共同构成功能安全概念FSC（Functional Safety Concept），该层面对应标准第3部分。

FSR进一步细化生产系统需求TSR（Technical Safety Requirement），对于它的实现为系统设计SYSD（System Design），TSR和SYSD共同构成TSC，该层面对应标准第4部分。

TSR再细化为硬件安全需求HSR和软件安全需求SSR，针对HSR的实现为硬件设计HD，一般包括架构设计、原理图设计、Layout，接下来进行量产指标（SPFM、LFM和PFHM）计算。对于软件也一样，依次为软件架构设计、单元设计（应用层ASW和底层BSW）、代码生成。而在SW和HW之间会有软硬件接口HSI，硬件部分对应标准第5部分，软件部分对应标准第6部分。

再加上硬件、软件和系统及整车测试，基本构成了主要框架。