前言

本篇图文跟大家分享一下基于高通8155的智能座舱仪表域功能安全设计。

全系内容可在《搞一下汽车电子》后台回复 “系列”，或进入菜单栏 “分享平台” –> “系列分享”

本系列请点击：《搞一下闲谈》

所有系列请点击：《汽车电子系列分享》

安全目标与功能

什么是功能安全

在分享之前，笔者先简单总结一些什么是功能安全？

字面意思上看，就是保证功能安全的运行。

从技术上来讲，就是更合理的异常处理。当然，并不是所有的异常都要处理。

汽车功能安全的标准是 ISO26262 ，其中对功能安全的定义是：

功能安全是为了避免因电气／电子系统故障产生的会引起危害的不合理风险。

从ISO 26262 对功能安全的定义可以看出，功能安全的范围只是针对电气/电子系统，物理故障不包括在内。

需不需要功能安全主要由以下三个方面来衡量：Severity 严重度， Exposure 曝光度，
Controllability 可控度。

严重度

危险发生时，导致的伤害的严重性，这个严重度是指对驾驶员及周边人员造成的健康
伤害的严重度。

曝光度

在操作条件下，暴露于危险当中的可能性，几乎不可能曝光的故障，不需要考虑功能
安全。

可控度

危险的可控性，主要是指当危险发生时，该危险可被司机、其他交通控制人员进行控
制并减小或避免危害发生的可能性。

Safety Goal

简单总结了一下什么是功能安全，接着笔者将根据功能安全的一般设计流程，从Safety Goal开始分享一下基于高通8155的智能座舱仪表域功能安全设计。

首先笔者从某OEM获取了关于Cluster相关的Safety Goal（安全目标）列表，均为ASIL-B等级。如下图所示。

主要有3个内容：
1.Cluster显示子系统需要能检出画面静止（frozen frame）
2.从传感器获得（需要被Cluster通过Telltale方式显示）的信息，需要保证正确显示。
3.信息显示的延迟应不大于300ms

了解Safety Goal之后，我们来看一下Safety Function。

Safety Function

下图为高通建议的达到上述Safety Goal的对应策略。

上图中，SF_1表示仪表需要完成的功能安全ID。SG_x表示 Safety Goal ID。

策略1

假定Safety Function的输入为：接收要显示的framebuffer。
假定Safety Function的处理为：在实际显示图像之前执行必要的处理步骤。
策略：显示子系统需要有能力检出画面静止，并在检出画面禁止的时候给MCU提供一个外部中断。

策略2

假定Safety Function的输入为：通过SPI或PCIe形式的车载接口处理器接收数据。
假定Safety Function的处理为：验证来自车辆接口处理器的与仪表盘显示相关的所有传入消息的 CRC。创建一个包含与每个 telltale 标志对应的图像的帧缓冲区，生成CRC并提供给显示子系统。
策略：应确保从传感器（仅限于提供仪表组显示相关信息的传感器）到显示器的数据捕获点的数据完整性。然后对然后对telltale的内容同时在MCU和SOC进行校验，需要在MCU侧进行出错处理。

策略3

假定Safety Function的输入为：通过SPI或PCIe形式的车载接口处理器接收数据。
假定Safety Function的处理为：验证来自车辆接口处理器的与仪表盘显示相关的所有传入消息的 CRC。创建一个包含与每个 telltale 标志对应的图像的帧缓冲区，生成CRC并提供给显示子系统。检查配置的帧速率并测量延迟。
策略：测量MCU收到CAN数据以及telltale被显示时的延迟时间，如果超过100ms，需要在MCU侧进行出错处理。

上述三个策略的容错时间间隔均为300ms。

安全功能实现

接下来，我们看一下Safety Function 实现。

关于策略1：

对于上节 Safety Function 中提到的策略1，需要Display 驱动IC 支持此功能。

关于策略2：

为实现上节 Safety Function 中提到的策略2，主要包含以下几部分内容。

Safety通道

MCU和SOC之间的通信需要走一条安全的有保障的通路，所以需要对消息进行CRC校验，如果MCU和SOC之间有2条通信通道，笔者建议是让FuSa相关的Telltale消息单独走一条通道。如下图

上图中，蓝色的为MCU与SOC之间正常的通信通道。
红色表示与FuSa相关的通道。

系统方案

针对策略2，笔者参考高通的文档（如下图所示），给出实现策略2的详细方案。

AOU_1
因为8155芯片无法达到ASIL-B等级，所以需要配合一颗能够达到ASIL-B等级的MCU来组成一个可以达到ASIL-B等级的系统。MCU负责从外部收取ASIL-B相关CAN信号的数据，该数据由SOC进行显示。

AOU_2
MCU和SOC之间的通信通路需要增加CRC校验机制。

AOU_3
笔者认为，是多个telltale需要同时做CRC校验的时候，添加一个frame counter来判断当前帧属于哪个telltale（异步方式）

AOU_4
MCU需要保存所有的ASIL-B相关telltale的CRC校验码表。

AOU_5
当MCU收到ASIL-B相关telltale信号时，需要对CRC校验码表进行查表操作。

AOU_6
MCU能够对SOC发回的CRC进行对比工作。

AOU_7
MCU需要在CRC对比出错的时候能够把整个系统置为安全状态（这里并没有说安全状态是什么，后续会讨论）。

AOU_8
MCU和SOC之间的通信通路需要有软件恢复的能力。（比如：* 消息发送失败时，重新建立连接 ** 消息CRC校验失败时，进行重传 *** 消息长时间发送失败时，重启SOC等）。

AOU_9
SOC需要有一个外部watchdog进行监控（这里可以由MCU来负责监控SOC定期的喂狗）。

AOU_10
AOU_9的补充。

AOU_11
AOU_9的补充。

AOU_12
需要由外部硬件把SOC置为安全状态（这里并没有说安全状态是什么，后续会讨论）。

AOU_13
MCU同时需要一个外部watchdog进行监控。

Use Case

针对策略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

比较加载的 CRC 和计算的 CRC。
将超级缓冲区发送到安全关键显示管道。
读回 HW 计算的CRC形式的显示管道末端（CRC-HW）并与计算的CRC（CRC-SW）进行比较。
需要注意的是，Telltale 的 Render 和 Check 应该分为两个应用。

– > SDM855A 发送 CRC-SW 到 VIP

VIP对CRC（CRC-SW vs CRC-VIP）做最终检查，如果不匹配，则中断SDM855A。
此处会对SOC产生一个中断。

– > SDM855A 发送最终的图像到 Display

在SOC测CRC校验完成后才最终显示到屏幕上。

关于策略3

在执行策略2的时候，可以连同一起把策略3执行掉。MCU检测收到CAN信号到最后MPU发来CRC值之间的时间间隔。

系统架构设计

根据上面的分析，系统大致的架构设计如下：

SOC侧模块

Telltale Renderer

接受MCU发送的Telltale Events，从Bitmap Table选择对应的Telltale Images。

计算Telltale Images的CRC-SW并和Bitmap Table中预存的CRC-STORED进行对比，发送包含CRC-SW的消息到MCU。
通过Telltale Pipeline，显示Telltale Events

Telltale Checker

接受MCU发送的Telltale Events，从Bitmap Table选择对应的Telltale Images。

计算Telltale Images的CRC-SW，使用MISR功能比对CRC-HW和CRC-SW，如出现错误则会产生一个中断。

Bitmap Table

可以是Hardcoding在代码中的一个静态数据表。
保存着Telltale Events和Telltale Bitmap的对应关系，保存着Telltale Bitmap。

MCU侧模块

Telltale Checker

保存Telltale状态，当状态变化时，发送Telltale Events给SOC。
等待SOC发送来的CRC-SW，如超时则做Safe State处理。

比较CRC-SW和本地保存的CRC-VIP的值，如不一致则做Safe State处理。

CRC Table

保存着CRC-VIP和Telltale Events的对应关系。

FuSA Channel

一条独立的通信通道（UART，SPI）。
具有带CRC校验的通信机制，并能保证通信出错时的恢复处理。

PIN for Safe State

一个外部中断或直接接SOC的RESET PIN，使得SOC进入Safe State。
高通提供的架构图（增加了笔者的个人理解）

Telltale显示相关

对用来显示Telltale的Pipeline，不允许做任何的Scale，Sharpen等Pixel Processing, Postprocessing处理，所以需要Bypass掉这些DU中的处理单元

显示Telltale的Pipeline在OpenWFD的xml配置文件中，必须时Z-Order最高的那个图层。

Telltale显示，不可以使用基于OpenGL ES等图形库描绘后生成的图像，必须使用原始的Bitmap。

高通8155硬件提供的MISR功能功能最多能Check 4个区域的CRC，所以在设计ASIL-B Telltale布局的时候需要合理设计。

Safe State 相关

关于SOC应该进入Safe State后应该如何动作，这里高通并没有给任何建议。这里我能想到的一般就是重启SOC，也可以伴随一定的Chime音提示。

当然，因为座舱类项目的SOC驱动着2块以上的屏幕，重启导致这些屏幕短暂的全黑屏可能会造成用户的恐慌和体验下降。所以Safe State的定义还需要进一步和OEM进行讨论研究。

本期的分享就到这里。后期我们也会分享基于R-Car H3 + RH850 的智能座舱功能安全设计。欢迎订阅哦~