在上回讲完功能安全的定义以后，"是什么" 和 "为什么" 的问题，我们已经搞懂了。接下来就要看看重点，"怎么样" 的问题。
主机厂在研发一款汽车平台的初期，会基于以往大量的工程和实际经验，把整车的功能细分到不同的子系统里，比如车载娱乐系统，底盘和驱动系统，辅助驾驶和车身照明系统等等。
以下以被动安全辅助系统来举例。
被动安全辅助系统，比如安全带和安全气囊就属于被动安全系统的一部分。假如汽车在发生碰撞以后，安全带会收紧，并且相应的安全气囊会弹出。
当主机厂划分子系统到安全气囊控制器的时候，当然要描述一下，这个控制器的功能，是否是一个电子设备，这个控制器与其他控制子系统的接口，还有例如法律法规的要求，比如被动安全系统是法律要求。这是在引入功能安全以前已经现成有的东西。
当现在加上功能安全，我们考虑安全气囊控制器的时候，主机厂会基于以往的经验，比如这个控制器在以往出现过什么问题，具体的原因是什么？例如曾经最大的安全气囊生产商高田就因为设计原因不得不召回而在日本申请破产。
基于这些对基础功能的描述和以往故障的分析，主机厂通过对安全气囊开发的范围做出划分和描述，这就是所谓的 ISO 在第三章 item 定义的要求。当然了，具体还有很多详细的内容，此处不一一展开。
当有了这些item的功能要求和故障信息，主机厂会在内部进行评定审核，主要的任务是，去判断当之前定义的item在不同工况出现不同故障的情况下，驾驶员和乘客是否受有威胁到人身安全的风险，以及去评定风险的等级。这就是顶顶有名的HARA (Harzard Analysis and Risk Assesment)
还是以安全气囊举例说明：
首先构想不同的使用情景：
汽车状态：
停车
驻车
行驶 0-30km/h
行驶 >30km/h
路况信息：
湿滑
干燥
市区
高速
道路信息：
弯道
直行
以下举例说明：
当安全气囊控制器的指示功能出现故障的时候：
- 汽车以20km/h的速度行驶在干燥路面的市区时
- 汽车以100km/h的速度行驶在湿滑的高速公路时
当安全气囊控制器的检测功能出现故障的时候：
- 汽车以20km/h的速度行驶在干燥路面的市区时
- 汽车以100km/h的速度行驶在湿滑的高速公路时
当安全气囊控制器出现故障自动弹出的时候：
- 汽车以20km/h的速度行驶在干燥路面的市区时
- 汽车以100km/h的速度行驶在湿滑的高速公路时
等等...(此处有成百上千行)
分别对下面三个因素进行量化分析：
- 对应故障发生事故的人员伤亡严重程度 --> S 代表severity
- 对应故障出现的频率 --> E 代表Exposure
- 驾驶员是否能控制汽车 --> C 代表Controllablity
并按照下图, 对号入座：1-3 代表不同的程度。进而得到相应风险 的ASIL 等级
最后取在不同情况下最高的ASIL等级为该产品研发时的功能安全要求等级。这个ASIL将伴随安全气囊供应商的整个研发以及售后流程，根据这个级别，将定义和划分对应软件，硬件等功能安全相关的工作。此处划重点，以后慢慢讲具体在供应商开发软件时如何根据ASIL来做相应的工作。
根据不同的风险，与之对应的是新加的功能安全需求。也就是安全目标 (safety goal).
例如：
SG1：如果安全气囊系统的检测传感器出现故障，驾驶员应该在汽车驾驶的过程中得到故障提醒。
SG2：在汽车行驶过程中，气囊不能在无碰撞的情况下弹出
等...
可能你会发现，有的功能安全需求跟功能需求大相径庭，这两个需求有部分重叠的情况，但是功能安全侧重于当出现故障，设备系统如何处理故障进而规避和降低对人造成的风险。而功能需求侧重于如何实现具体的功能。实现功能是功能安全的基础。所以往往在研发过程中，功能安全研发工作会比功能开发工作晚开始，比较绕口，请见谅。可以简单理解为，第一步实现所有的功能，当部分功能与功能安全需求相关时，需要做额外的工作来保证此功能安全。
我们知道，汽车领域的需求，设计都要对应相应的测试结果。安全目标(safety goal) 对应的就是将来非常麻烦的并且需要独立第三方评测的 safety case,这个我们以后文章会提到。
写到这里，意犹未尽，下回再见吧。