8.AUTOSAR 诊断栈分析(一)

目录

1.错误分级分类

2.错误上报方法

[2.1 API上报](#2.1 API上报)

[2.2 预定义的Callout上报](#2.2 预定义的Callout上报)

[2.3 DET(Default Error Tracer)相关Hook或者Callout上报](#2.3 DET(Default Error Tracer)相关Hook或者Callout上报)

[2.4 DEM相关错误处理](#2.4 DEM相关错误处理)

[2.5 DLT相关错误处理](#2.5 DLT相关错误处理)

3.小结


终于来到了整个ECU的核心:诊断Dianostic。

为了更加系统地了解诊断,我将从错误分级分类、错误上报方法、诊断模块几个方面进行分析。

1.错误分级分类

根据AUTOSAR相关简介,在ECU系统级别的错误等级如下四类:

  • 开发错误(Development Errors)

这种错误类型很常见,在开发期间用来定位软件bug;

例如某些模块没初始就开始使用、错误的数据长度等;

随着ECU的量产上车该类错误的检测机制需要关闭。

  • 运行时错误(Runtime Errors)

该类错误属于比较严重的系统级软件错误,但是也是需要根据实际情况记录。

例如在运行过程中,收到的CAN报文突然丢掉了(Buffer里没数据了)。

  • 瞬态故障错误(Transient Faults)

瞬态故障错误一般发生在硬件,这个我暂时还没有看到过。

  • 产品错误(Production Errors)

这个很好理解了,就是定义的某些DTC,用于量产车日常的维修诊断使用。

那么上述错误从类型来看,又分为:

  • 硬件失效/错误

例如Flash模拟EEPROM失效,不能写入等

  • 软件错误

例如调用NvM_Write时输入了错误的地址信息等

  • 系统错误

这个就不太好分辨,例如某报文接收超时,无法判断是软件还是硬件错误;故定义成系统错误,需要进一步处理。

2.错误上报方法

AUTOSAR定义了如下几种方法进行错误上报。

2.1 API上报

该方法是通过读取调用某个API后的返回值获得该API操作是否成功。这么说起来比较绕,还是具体示例:

cpp 复制代码
Std_ReturnType Dem_ClearDTC (uint8 ClientId)

如上,Std_ReturnType有两种返回值E_OK和E_NOT_OK,用于表示当前清除DTC的操作是否成功,用户根据返回接口去做对应的代码逻辑。

注意,这里要与我们调用DEM相关API设置DTC状态不一样的,下面会讲到。

2.2 预定义的Callout上报

当某个操作出现错误时设计一个callout,例如CAN报文接收timeout,此时通过callout上报。

2.3 DET(Default Error Tracer)相关Hook或者Callout上报

DET主要是上报开发错误和运行时错误。

这意味着,在开发阶段DET用于上报开发错误,量产阶段DET根据情况上报系统错误。所以以前我们常说上车后DET是需要关闭的这种说法不是非常准确。

该方式常见的机制有:

  • 将错误信息写入ring buffer
  • 将错误信息通过串口输出到外部logger
  • 死循环等

提供的接口有:

cpp 复制代码
Det_ReportError(uint16 ModuleId, uint8 InstanceId, uint8 ApiId, uint8 ErrorId)

ModuleID:一般指AUTOSAR定义的基础软件模块ID

IntanceID:该模块的示例ID,例如CAN0\1\2

ApiID:对应模块的API ID

ErrorID:对应错误ID

2.4 DEM相关错误处理

DEM错误上报,就是大家平时接触的最多的错误处理地方时,用于上报主机厂定义的错误,通常是通过将错误事件写进memory、禁用某些ECU功能(FIM:Function Inhibition Manager)或者通知某些SW-C。

该模块提供的接口如下:

cpp 复制代码
Dem_SetEventStatus(EventId, EventStatus)

这块的事件管理会在后面详细说明。

2.5 DLT相关错误处理

DLT(Diagnostic Log and Trace)用于收集错误信息并转为标准格式,然后将数据传给PduR,经由PduR通过不同总线传输到PC或者记录仪。

该模块有如下功能:

  • 提供标准接口用于记录SW-Cs、Det、Dem等模块提供的错误信息
  • 结合RTE使用Trace
  • 可以单独对log、trace信息进行使能
  • Dlt在开发和量产阶段均可以使用

需要重点关注的是,量产阶段DLT的log和trace信息必须要信息安全机制保证。

常用API为:

cpp 复制代码
Dlt_SendLogMessage(Dlt_SessionIDType session_id, 
Dlt_MessageLogInfoType log_info, 
uint8 *log_data, 
uint16 log_data_length)

DLT常见的使用方法如下:

  1. SW-C生成一个log信息,并调用DLT标准接口将信息发送给DLT
  2. DLT模块通过DLT协议将数据转为标准格式;
  3. 通过PduR将数据传给目标总线
  4. 编码后的数据传给目标PC。

3.小结

通过上面简介,我们主要了解了在ECU层级下的错误分级分类、错误上报机制。

对故障处理,大家可能首先就想到了DEM和DET;

对于API这类虽说也在用,但是还没有上升到故障这种想法;

DLT就更不用说了,以前大家有打印log的习惯,但是没有一个统一的标准。

下面我们将详细聊DEM、DCM,有机会在聊聊DLT吧。

相关推荐
嵌软小白呗13 小时前
Autosar-SecOC功能详解(一)
e2e·can·autosar·crc·secoc
行者-全栈开发3 天前
Spring AI + GPT-4 实战:API Key 安全管理与企业级集成方案(避坑指南)
openai api·错误处理·密钥管理·spring ai·企业级开发·请求封装·api 安全
审判长烧鸡3 天前
GO错误处理【4】报错即链条
go·异常处理·错误处理
审判长烧鸡4 天前
GO错误处理【5】显式错误处理
go·错误处理·报错链条
内容为空5 天前
TC397 CAN 模块硬件资源与配置详解笔记
autosar
阿歪i7 天前
EB 配置MCAL (1)
s32k144·autosar·mcal
内容为空7 天前
AUTOSAR COM 模块:ComIPduGroup 与 ComSignalGroup 区别笔记
autosar
老歌老听老掉牙7 天前
Python 错误处理:从基础语法到工程级实践的完整指南
python·错误处理
zmj3203249 天前
UDS 0x27 安全访问(种子 / 密钥 Seed-Key) 的用法、流程、算法、存储位置、安全机制
安全·can·诊断·uds·27服务
MESMarketing13 天前
互动分享 | 软件工具的安全合规实践
功能测试·测试工具·matlab·ci/cd·autosar