上回更新到主机厂在内部做危险分析和风险评估(HARA), 进而定义了安全目标（Safety Goal), 这篇会基于安全目标继续进行下去。
主机厂引入了下一个阶段的工作，名字叫“功能安全概念” （functional safety concept）中文概念比较难理解，这是一个concept，但是中文的定义是“概念”，个人认为翻译的不是很好。我宁愿把它当做一个 “构想” 或者 “实施的方法”，这个过程主要是为了通过之前定义的安全目标，来确定具体的功能安全需求。并将它们初步的分配到设计架构中，以满足实现功能安全的终极目标，让“所有的风险都变得可以接受”，（absense of unresonable risk）忘记的话，回头看看第二篇文章。
这里有个非常重要的实践经验，就是在这个阶段，主机厂或者部分一级供应商要把实现基础功能的需求和功能安全需求分开。这样不仅能在未来的工作中，节省大量的人力和时间，也可以让整个功能安全架构显得清晰和有条理。
还是拿我们的安全气囊举例吧
具体在零件层面 （componet level）的功能要求有
检测汽车是否碰撞功能
读取汽车当前状态功能
安全气囊弹出功能等....
而安全功能需求譬如有：
安全气囊控制器自检功能和失效缓解功能，以及故障显示提醒功能
安全状态转换功能 （比如：在判断无碰撞但是弹出触发的时候，安全气囊保持不弹出状态（safe state））
故障容错机制 （比如四个加速度传感器中有一个出现故障）和仲裁机制等....
以上需求，如有雷同，纯属巧合，我没做过关于汽车安全气囊的工作，可能会有错误，但是此处的目的是为了说明如何理解功能安全的具体步骤，大伙看的话就图一乐呵就行。
通过这一个"概念" 阶段, 在分析完不同的功能目标(safety goal) 并且细分到功能需求和功能安全需求之后，大概如下图所示：
功能安全需求会带着自身的安全等级属性分配到不同的子系统中。而这里的功能安全需求不同于普通的功能需求，有很多特殊的地方，ISO在功能安全需求的来源和功能安全需求的分配上，有一定的建议和要求。
比如对功能安全需求来源的要求有：
应该从功能安全目标和安全状态来获得。
每一个功能安全目标都必须有一个或多个相应的功能安全需求。
在起草和定义每个功能安全需求时都要有以下属性：操作模式，故障容错时间间隔，安全状态，功能冗余，急停操作间隔等
在功能安全的分配上：
如果子系统继承了多个功能安全目标，以最高的ASIL等级为该子系统的安全等级，并且相应的信息需要继续传承到该子系统的下属子系统。
如果要分解功能安全等级要求，需要按照 26262-9 第五条款的要求
等其他很无聊并且很枯燥的要求。
如果你能看到这里，说明你对功能安全情有独钟。希望你坚持看这个系列，因为后面会更没意思。
开玩笑的，大概理解下这个概念阶段之后，下一篇就可以具体到功能安全的实现上，就会有趣的多。
后会有期，不见不散。