前几天NXP的罗总有一个功能安全的讲座，一天的课程主要是对基本概念的理解，就参会人员来说，感觉对功能安全概念的普及还需要加强，为什么人才市场上的功能安全工程师或功能安全经理是香饽饽就容易理解了。

前几天NXP的罗总有一个功能安全的讲座，一天的课程主要是对基本概念的理解，就参会人员来说，感觉对功能安全概念的普及还需要加强，为什么人才市场上的功能安全工程师或功能安全经理是香饽饽就容易理解了。

实际上，功能安全并非是最近才有的产物，其它行业也有类似的要求，最近几年慢慢在汽车行业上流行起来。

从根源上来说，它并不新鲜，很多的工作在我们以前的工作中均有体现，而功能安全概念的提出，实际上是对开发流程的标准化的一个过程。

ISO 26262-2011版对功能安全的定义是主要用于安装在最大毛重不超过3.5吨的量产乘用车上的一个或多个E/E系统的安全相关系统，而国标GB/T 34590-2017修改采用了ISO 26262，在适用范围上，去掉了3.5吨的限制。

了解了功能安全解决的问题是什么，就可以针对性的解决，功能安全面对的环境是车辆技术的提升，电子产品越来越多，软件越来越多，机电一体化的产品越来越多，主要解决的是系统性风险及随机硬件失效。而系统性风险主要跟产品的设计及流程相关，而随机硬件失效则主要跟硬件、芯片厂商相关。

从公司角度，需要有功能安全文化、功能安全概念、管理流程及相应的支撑流程，而产品开发角度，则有一系列的功能安全分析方法和产品设计方法。从整车的Feature层面，到系统，再到部件。

从整车开发角度来说，HARA是整车High level的开发，它与车辆的Feature息息相关，通过对Feature的识别，识别出Hazards，进行量化分析，确定ASIL等级，最后可以得到安全目标。功能安全的开发从上到下也是从整车级别Feature到component的开发。

安全目标是经HARA分析后提炼后的功能安全需求，包括了四方面的属性：安全描述，ASIL等级，安全状态，故障容错时间间隔。这四方面完整的定义是我们理解某一产品的安全目标，制定相应的措施的前提。

功能安全概念的目标是提炼出来的功能安全要求，它从安全目标出发，将其分配给各个子部分或其它外部的措施。它的主要定义在故障检测及失效减缓、安全状态的传递、故障容忍机制及驾驶员提醒等方面。

功能安全的开发并非是新增及创造新的工作量，很多都是将原来的工作内容结合功能安全流程进行输出。硬件开发流程上，同样采用V模型开发，从需求出发、到设计及验证。

对于软件开发来说，AUTOSAR属于建议性的，可以提供安全方法和机制以支持安全相关系统的开发，采用AUTOSAR的架构也并不意味着符合功能安全要求。而满足ASPICE流程的软件开发通常认为是满足功能安全的开发。

功能安全相关评估（Assessment），功能安全Audit、Review、Assessment在不同阶段或项目有不同的要求，不同的ASIL等级适用的要求也不同。

功能安全评估的建议，理解了评估的内容，其实也是对功能安全的过程的理解，也是对功能安全在企业内是否真正实施的理解。

功能安全是规范化开发流程的一种手段，它不是强制，但在越来越多主机厂认同的情况下，需要电子电气工作人员关注，而关注功能安全的前提，是对其的理解。

功能安全不是为了增加工程量，很多的开发思想都与我们平时工作的一致，通过功能安全的理解，对开发流程正规化，可以降低产品风险，增加安全。

汽车测试网-创办于2008年，报道汽车测试技术与产品、趋势、动态等 联系邮箱 marketing#auto-testing.net (把#改成@)