基于 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和M1~M9，D1~D9 ）和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线程会停止发心跳，然后系统就会重启。

本期分享就到这里，我们下期见。

后 语

如有兴趣进入技术交流群交流，可联系小编微信

联系我们

[e-mail]

结  束