前言
之前我们分享了基于8155的智能座舱功能安全设计，也介绍了功能安全的基本概念，本篇文章给大家分享一下基于 H3 + RH850 的智能座舱功能安全设计。
全系内容可在《搞一下汽车电子》后台回复 “系列”，或进入菜单栏 “分享平台” --> “系列分享”
本系列请点击：《搞一下闲谈》
所有系列请点击：《汽车电子系列分享》
概述
需求
针对基于H3和RH850的智能座舱功能安全概览如下：
RH850检测功能安全相关的CAN FD信号，这些信号同时被RH850发送到A53和R7。A53上面的主HMI根据信号描绘报警灯并输出，R7会同时监控主HMI描绘的报警灯。当R7检测到主HMI描绘错误时，R7会接管显示输出功能安全相关报警灯信号。
RH850检测功能安全档位显示相关的CAN FD信号，这些信号同时被RH850发送到A53和R7。A53上面的主HMI根据信号描绘档位显示输出，R7会同时监控主HMI描绘的档位显示。当R7检测到主HMI描绘错误时，R7会接管显示，输出熄灭档位。
功能安全保护的报警灯和挡位信息如下表所示：
上表中，ASIL（汽车安全完整性）等级划分为：A、B、 C、D四个等级。
其中，A为安全等级最低，D为安全等级最高。
硬件支持 (DOC)
在做功能安全实现时，软硬件都要求是功能安全的，瑞萨提供的R7 Core具备Duplicated Hardware、 ECC、EDC、CRC、MPU、DOC等安全机制。其中关于报警灯的输出检测主要是DOC（Display Output Checker）模块完成的。如下图所示。
软件架构
在软件架构设计方面，我们将 LSR是跑在在R7 Core上，最终R7 Core上跑的是Safety RTOS。
LSR主要是接受VIP的消息，然后控制DOC检测报警灯和挡位的输出是否正确，如果不正确，则进入安全状态，通过VSP进入纠正。如下图所示。
LSR结构
LSR 结构如下：
•Safe Core：各种消息处理，HMI元素的Visible/Invisible属性设置
•HMI：以C数组的形式存放二进制的素材
•LSR(Luxoft Safe Renderer)：Render和Verify相关的Framework
•GIL(Graphical Interface Layer)：提供了Render和Verify底层寄存器操作相关的接口
Safe Core
Message处理
在Message处理方面，设定以下机制：
每一个消息都有一个对应的消息处理类
重要的消息会周期性发送
周期性消息会有Timeout检测，连续3帧Timeout之后，R7进入安全状态，连续5帧消息正常，则退出安全状态
周期性消息都有CRC检测，连续3帧Error之后，R7进入安全状态，连续5帧消息正常，则退出安全状态
周期性消息都有Rolling Counter检测，连续3帧Error之后，R7进入安全状态， ，连续5帧消息正常，则退出安全状态
周期性消息的每一位数据都要有Check Sum，高四位和低四位取反，然后和要是0x0F，例如：0xE1:高位取反0x01，低位取反：0x0E，和是0x0F为正常的数据；0xE2: 高位取反0x01，低位取反：0x0D，和是0x0E为错误的数据。连续3次Error之后，该位数据对应的功能进入安全状态，连续5帧消息正常，则退出安全状态
HMI Control
HMIControl通过引用的关系，修改各个元素的可见性状态（ Panel, ReferenceBitmapField, BitmapField ）
每个元素只有可见和不可见两种属性
HMI总共有23个Gear状态（ P，R，N， D，Blank和M1M9，D1D9 ）和14个TT状态需要设置。
LSR
LSR实现了Engine部分，这个组件是Framework层，与项目需求没有太大关联。功能是把HMI状态转换成底层GIL命令。
lsr :: Engine包含了lsr的完整功能。它被分解为3个主要组成部分：
lsr :: Database提供对静态HMI配置的访问（例如bitmap的大小位置等）
lsr :: DisplayManager为GIL硬件接口提供C ++抽象
lsr :: FrameHandler实现HMI的动态行为IHMI接口提供对HMI运行时对象（ Panels，Fields）的访问。这些运行时对象是静态创建的，但由lsr :: Framehandler控制。
Database
Database只是一个DDHType的引用
•DDHType是静态HMI资源的根节点。通过bitmap ID可以访问任意的位图像素数据。
•lsr :: * Type都是POD（Plain Old Data）结构（DDHType， PanelType等），以便于静态HMI设计。
•DDHType是静态HMI资源的根节点。通过bitmap ID可以访问任意的位图像素数据。
•lsr :: * Type都是POD（Plain Old Data）结构（DDHType， PanelType等），以便于静态HMI设计。
•DDHType是静态HMI资源的根节点。通过bitmap ID可以访问任意的位图像素数据。
•lsr :: * Type都是POD（Plain Old Data）结构（DDHType， PanelType等），以便于静态HMI设计。
Display Manager
DisplayManager类为gil.h(硬件访问接口)提供了C ++抽象。
•DisplayManager为GILContext提供了C ++抽象
•Texture为GILTexture提供了C ++抽象
•WindowCanvas封装了GILSurface。它提供了用于绘制位图和验证位图区域的操作。
实现细节：
•可以通过DisplayManager :: loadAllTextures（）一次加载所有纹理。
•调用TextureCache :: load()加载一个Texture，如果该Texture不存在，将会创建一个Texture。
Frame handler
FrameHandler管理和操作所有的元素。每次执行，会遍历所有元素的属性，然后根据属性对每一个元素进行隐藏/绘制/验证等操作。
Window：Window是管理硬件Layer的类，它包含WindowCanvas，所有子元素最终都在Window中执行绘制/验证操作。
Frame：Frame是管理软件Panel的类，根据项目需要可以创建多层Panel。但现在只支持同时显示一个Panel，不支持多个Panel的合成和透过。
Panel是Field的简单容器。如果Panel设置不可见，则Panel下的所有Field都不可见。
Field是实际执行绘图或验证操作的元素。
GIL
Overview
GIL实现了底层渲染和检测的接口，GIL提供了一层标准的C接口，然后以GILImplRCarX3类实现了针对R-car的功能。
•DocHandler：实现了图像check的寄存器操作。
•Vspd：实现了窗口render的寄存器操作
DOCHandler
•DOCHandler：实现了DOC一些通用的寄存器
•MonitorHandler：管理各个Video Output Monitor的状态，最大只能开启16个monitor，不能两个及以上的Monitor同时Check一个图片。
•VideoOutputMonitor：管理一个Monitor的寄存器。R-Car硬件把DOC的RAM分成16组寄存器，每个VideoOutputMonitor对象管理一组（1024个）32位寄存器。monitor0: 0…1023
monitor1: 1024…2047
每个寄存器包含8个像素，即每个监视器控制一个8192像素的区域（相当于128x64像素的图像）
寄存器设置参考瑞萨提供的流程图，左边部分是在DOCHandler类中完成，右边部分是在VideoOutputMonitor类中完成。
VSPD
•VSPD使用最上层的硬件layer来渲染LSR的Frame Buffer，所以LSR的输出都是叠加在QNX的页面之上。
•该实现是先取到QNX设置到寄存器里的Display List的首地址，然后在List的最后追加LSR的Display配置，重新设置Display List属性。
•每个执行周期内，都从首地址开始重新遍历QNX的Display List属性，然后重新设置。这要求QNX运行中不能修改DisplayList的首地址。
LSR执行流程
LSR线程按照接收消息->设置属性->描绘->检测->寄存器检查的流程来周期执行。
如果有任何寄存器Error或者HMI描绘Error，LSR线程会停止发心跳，然后系统就会重启。
本期分享就到这里。如果大家有其他方面的点，也欢迎补充！
联系我们
微信：shactiontech
邮箱：support@
