在分享之前，笔者先简单总结一些什么是功能安全？
字面意思上看，就是保证功能安全的运行。
从技术上来讲，就是更合理的异常处理。当然，并不是所有的异常都要处理。
汽车功能安全的标准是 ISO26262 ，其中对功能安全的定义是：
功能安全是为了避免因电气／电子系统故障产生的会引起危害的不合理风险。
从ISO 26262 对功能安全的定义可以看出，功能安全的范围只是针对电气/电子系统，物理故障不包括在内。
需不需要功能安全主要由以下三个方面来衡量：Severity 严重度， Exposure 曝光度，
Controllability 可控度。
严重度
危险发生时，导致的伤害的严重性 ，这个严重度是指对驾驶员及周边人员造成的健康
伤害的严重度。
曝光度
在操作条件下，暴露于危险当中的可能性，几乎不可能曝光的故障，不需要考虑功能
安全。
可控度
危险的可控性，主要是指当危险发生时，该危险可被司机、其他交通控制人员进行控
制并减小或避免危害发生的可能性。
简单总结了一下什么是功能安全，接着笔者将根据功能安全的一般设计流程，从Safety Goal开始分享一下基于高通SD8155的智能座舱仪表域功能安全设计。首先笔者从某OEM获取了关于Cluster相关的Safety Goal（安全目标）列表，均为ASIL-B等级。如下图所示。1. Cluster显示子系统需要能检出画面静止（frozen frame）2. 从传感器获得（需要被Cluster通过Telltale方式显示）的信息，需要保证正确显示。了解Safety Goal之后，我们来看一下Safety Function。下图为高通建议的达到上述Safety Goal的对应策略。上图中，SF_1表示仪表需要完成的功能安全ID。SG_x表示 Safety Goal ID。假定Safety Function的输入为：接收要显示的framebuffer。假定Safety Function的处理为：在实际显示图像之前执行必要的处理步骤。策略：显示子系统需要有能力检出画面静止，并在检出画面禁止的时候给MCU提供一个外部中断。假定Safety Function的输入为：通过SPI或PCIe形式的车载接口处理器接收数据。假定Safety Function的处理为：验证来自车辆接口处理器的与仪表盘显示相关的所有传入消息的 CRC。创建一个包含与每个 telltale 标志对应的图像的帧缓冲区，生成CRC并提供给显示子系统。策略：应确保从传感器（仅限于提供仪表组显示相关信息的传感器）到显示器的数据捕获点的数据完整性。然后对然后对telltale的内容同时在MCU和SOC进行校验，需要在MCU侧进行出错处理。假定Safety Function的输入为：通过SPI或PCIe形式的车载接口处理器接收数据。假定Safety Function的处理为：验证来自车辆接口处理器的与仪表盘显示相关的所有传入消息的 CRC。创建一个包含与每个 telltale 标志对应的图像的帧缓冲区，生成CRC并提供给显示子系统。检查配置的帧速率并测量延迟。策略：测量MCU收到CAN数据以及telltale被显示时的延迟时间，如果超过100ms，需要在MCU侧进行出错处理。
接下来，我们看一下Safety Function 实现。
对于上节 Safety Function 中提到的策略1，需要Display 驱动IC 支持此功能。为实现上节 Safety Function 中提到的策略2，主要包含以下几部分内容。MCU和SOC之间的通信需要走一条安全的有保障的通路，所以需要对消息进行CRC校验，如果MCU和SOC之间有2条通信通道，笔者建议是让FuSa相关的Telltale消息单独走一条通道。如下图所所以。上图中，蓝色的为MCU与SOC之间正常的通信通道。针对策略2，笔者参考高通的文档（如下图所示），给出实现策略2的详细方案。因为SD8155芯片无法达到ASIL-B等级，所以需要配合一颗能够达到ASIL-B等级的MCU来组成一个可以达到ASIL-B等级的系统。MCU负责从外部收取ASIL-B相关CAN信号的数据，该数据由SOC进行显示。MCU和SOC之间的通信通路需要增加CRC校验机制。笔者认为，是多个telltale需要同时做CRC校验的时候，添加一个frame counter来判断当前帧属于哪个telltale（异步方式）MCU需要保存所有的ASIL-B相关telltale的CRC校验码表。当MCU收到ASIL-B相关telltale信号时，需要对CRC校验码表进行查表操作。MCU需要在CRC对比出错的时候能够把整个系统置为安全状态（这里并没有说安全状态是什么，后续会讨论）。MCU和SOC之间的通信通路需要有软件恢复的能力。（比如：* 消息发送失败时，重新建立连接 ** 消息CRC校验失败时，进行重传 *** 消息长时间发送失败时，重启SOC等）。SOC需要有一个外部watchdog进行监控（这里可以由MCU来负责监控SOC定期的喂狗）。需要由外部硬件把SOC置为安全状态（这里并没有说安全状态是什么，后续会讨论）。针对策略2，笔者这里给出结合自己理解的实现时序图，如下图所示。在上图中，我们假设传感器以及 ”传感器2VIP 通信“ 是ASL-B的。假设Use：VIP 是 ASIL-B的。-- > N_Sensor 打开/关闭在CAN或其他车载总线上的 vector X这里的vector X 表示所有ASIL-B相关的Telltale 状态的组合。然后为 vector X 加载预先计算的 CRC：'CRC-VIP'（预计算CRC存储在VIP闪存表中）。-- > VIP 发送 vector X 数据（AOU：芯片间通信通过CRC，帧计数器等是ASIL-B。）到 SDM855A根据接收的 vector X，选择要在显示器上显示的图像作为Telltale region。-- > SDM855A 从DDR中获取每个Telltale 标志的每个状态的图像创建一个超级缓冲区，包含所有Telltale 的状态在 SW 中计算 CRC super 缓冲区：CRC-SW-- > SDM855A 从 DDR 加载超级缓冲区的 CRC（为存储为表格的每个向量预先计算的 CRC)：CRC-stored读回 HW 计算的CRC形式的显示管道末端（CRC-HW）并与计算的CRC（CRC-SW）进行比较。需要注意的是，Telltale 的 Render 和 Check 应该分为两个应用。-- > SDM855A 发送 CRC-SW 到 VIPVIP对CRC（CRC-SW vs CRC-VIP）做最终检查，如果不匹配，则中断SDM855A。-- > SDM855A 发送最终的图像到 Display在执行策略2的时候，可以连同一起把策略3执行掉。MCU检测收到CAN信号到最后MPU发来CRC值之间的时间间隔。接受MCU发送的Telltale Events，从Bitmap Table选择对应的Telltale Images。计算Telltale Images的CRC-SW并和Bitmap Table中预存的CRC-STORED进行对比，发送包含CRC-SW的消息到MCU。通过Telltale Pipeline，显示Telltale Events接受MCU发送的Telltale Events，从Bitmap Table选择对应的Telltale Images。计算Telltale Images的CRC-SW，使用MISR功能比对CRC-HW和CRC-SW，如出现错误则会产生一个中断。可以是Hardcoding在代码中的一个静态数据表。保存着Telltale Events和Telltale Bitmap的对应关系，保存着Telltale Bitmap。保存Telltale状态，当状态变化时，发送Telltale Events给SOC。等待SOC发送来的CRC-SW，如超时则做Safe State处理。比较CRC-SW和本地保存的CRC-VIP的值，如不一致则做Safe State处理。保存着CRC-VIP和Telltale Events的对应关系。具有带CRC校验的通信机制，并能保证通信出错时的恢复处理。一个外部中断或直接接SOC的RESET PIN，使得SOC进入Safe State。对用来显示Telltale的Pipeline，不允许做任何的Scale，Sharpen等Pixel Processing, Postprocessing处理，所以需要Bypass掉这些DU中的处理单元显示Telltale的Pipeline在OpenWFD的xml配置文件中，必须时Z-Order最高的那个图层。Telltale显示，不可以使用基于OpenGL ES等图形库描绘后生成的图像，必须使用原始的Bitmap。高通SD8155硬件提供的MISR功能功能最多能Check 4个区域的CRC，所以在设计ASIL-B Telltale布局的时候需要合理设计。关于SOC应该进入Safe State后应该如何动作，这里高通并没有给任何建议。这里我能想到的一般就是重启SOC，也可以伴随一定的Chime音提示。当然，因为座舱类项目的SOC驱动着2块以上的屏幕，重启导致这些屏幕短暂的全黑屏可能会造成用户的恐慌和体验下降。所以Safe State的定义还需要进一步和OEM进行讨论研究。
