直播回顾：从这里开始，学做高效的功能安全开发

汽车学堂联合优策科技组织的汽车功能安全主题直播第3期，8月10日线上直播回放部分精彩内容回顾。

前面分享过什么是功能安全和预期功能安全的概念。本期分享如何做高效的功能安全开发！

在汽车功能安全开发过程中，关键的细节该如何处理，例如：如何定义功能安全目标，将功能安全目标进行逐层的分解，如何选取分析工具等等。

// 精彩回顾

本次嘉宾老师

周老师，功能安全技术总监，曾在某大型零部件公司负责功能安全产品开发。现从事功能安全开发、项目、工程的咨询服务。

Q：功能安全目标什么时候确定？

A: 一般是先确定功能，再根据功能分析出概念阶段的安全目标，确定安全目标之后得到功能安全需求。一般在主机厂的项目竞标阶段，会提供一份关于客户需求（功能、性能、测试、验证等要求）的文档，这份文档会给到潜在的供应商进行报价和评估。

一般是先有功能安全目标，再分解到具体的开发任务中，形成功能安全需求，给到供应商。

Q：汽车产品开发周期长，在漫长的开发周期中，主机厂或者供应商是否会变更功能安全目标？

A: 理论上是可以的。根据功能安全标准中的准则，在安全分析或者系统架构设计过程中，先识别的尚未被功能安全目标覆盖的危害，应该更新到标准规定危害中，更新迭代之前那份功能安全分析的文档。从技术角度出发，是有可能在产品开发周期过程中变更功能安全目标。

但是在实际开发过程中，往往不会遇到。因为功能安全的需求和目标多少、高低、等级的不一样，会显著影响各个供应商的开发时间和周期。供应商在已经进入研发周期内，如软件架构、芯片等已经确定完毕的时候，更改功能安全目标的情况，意味着架构需要推翻重新制定，芯片也需要重新选取，等同于是灾难性的事故。 

所以一般在实际开发过程中不会遇到中途更改功能安全目标的情况。会严格按照确定好的功能安全目标来执行。

Q：如何把一个系统的功能安全目标分解到软件、硬件？

A:一般系统阶段，会将主机厂提交的功能安全需求转化成技术安全需求。而技术安全需求里面的要素会要求明确分配到软件、硬件，比如这一条技术安全需求分配给硬件来实施，还是分配给软件实施，还是同时分配给软硬件，由硬件提供平台，软件来具体完成实施。

不论是需求的分配还是系统的架构，都需要指定是软件实施还是硬件实施。

Q：功能安全目标ASIL是如何分解的？

A:功能安全目标等级分解原则。ISO 26262标准已经给出了明确的依据和参考，罗列了所有可以分解的情况。

功能安全目标可以分解的原因是,目标分解之后并不会降低分解之前要求的ASIL等级。例如，ASIL-D分解成C+A,只是降低了实施的成本或者难度，并没有降低需求，依旧可以达到ASIL D等级。

错过回放的同学，可以联系堂主，领取回放学习！