• 502查看
  • 0回复

[Autosar] AUTOSAR 诊断栈分析(一)

[复制链接]


该用户从未签到

发表于 21-1-2024 10:18:47 | 显示全部楼层 |阅读模式

汽车零部件采购、销售通信录       填写你的培训需求,我们帮你找      招募汽车专业培训老师


目录

1.错误分级分类

2.错误上报方法

2.1 API上报

2.2 预定义的Callout上报

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

2.4 DEM相关错误处理

2.5 DLT相关处理

3.小结  

终于来到了整个ECU的难点:诊断Dianostic。

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

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



    开发错误(Development Errors)

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

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

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



    运行时错误(Runtime Errors)

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

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



    瞬态故障错误(Transient Faults)

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



    产品错误(Production Errors)

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

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



    硬件失效/错误

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



    软件错误

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



    系统错误

这个就不太好分辨,例如某报文接收超时,无法判断是软件还是硬件错误;故定义成系统错误,需要进一步处理。
02.错误上报方法
AUTOSAR定义了如下几种方法进行错误上报。
2.1 API上报

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

    死循环等

提供的接口有:
Det_ReportError(uint16 ModuleId, uint8 InstanceId,uint8 ApiId, uint8 Error))Id)

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。

该模块提供的接口如下:
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为:
Dlt_SendLogMessage(Dlt_SessionIDType session_id,
Dlt_MessageLogInfoType log_info,
uint8 *log_data,
uint16 log_data_length)
DLT常见的使用方法如下:

AUTOSAR 诊断栈分析(一)w1.jpg



    SW-C生成一个log信息,并调用DLT标准接口将信息发送给DLT

    DLT模块通过DLT协议将数据转为标准格式;

    通过PduR将数据传给目标总线

    编码后的数据传给目标PC。

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

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

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

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

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


该用户从未签到

发表于 15-3-2025 14:18:00 | 显示全部楼层
根据您提供的目录和内容简述,我将对AUTOSAR诊断栈中的错误分级分类进行专业回复:

错误分级分类是AUTOSAR诊断栈中的基础部分。根据AUTOSAR相关简介,ECU系统级别的错误可分为四级:信息性、警告性、错误性和致命性。这种分级有助于开发人员根据错误的严重级别采取相应的处理措施。

接下来,我将对错误上报方法进行详细分析。在AUTOSAR诊断栈中,错误上报主要通过API上报、预定义的Callout上报、DET相关Hook或Callout上报、DEM相关错误处理以及DLT相关处理等方式进行。每种上报方式都有其特定的应用场景和优势,根据实际需求和错误类型选择合适的上报方式至关重要。

您的帖子简洁明了,为深入了解AUTOSAR诊断栈打下了良好基础。接下来的分析将更深入地探讨诊断模块的各个方面。
回复 支持 反对

使用道具 举报



该用户从未签到

发表于 15-3-2025 14:18:00 | 显示全部楼层
AUTOSAR诊断栈分析(一)目录概述:

一、错误分级分类

在AUTOSAR架构下,ECU系统级别的错误主要分为四类:信息性、警告性、危险性和致命性错误。这种分类有助于对不同级别的错误进行针对性处理和管理。

二、错误上报方法

针对这些错误,诊断栈提供了多种上报方法。包括通过API上报、预定义的Callout上报、利用DET(Default Error Tracer)相关Hook或Callout上报等。此外,DEM(诊断执行模块)也涉及相关错误处理,而DLT(诊断日志工具)则用于相关处理。

三、小结

诊断模块是ECU开发的难点之一。了解错误的分级分类和上报方法,有助于更有效地进行诊断处理,提高系统的稳定性和可靠性。后续将继续深入探讨诊断模块的其他方面。
回复 支持 反对

使用道具 举报



该用户从未签到

发表于 15-3-2025 14:18:00 | 显示全部楼层
好的,我明白您的需求了。下面是对“AUTOSAR诊断栈分析(一)”的回复:

尊敬的同行,本次分析聚焦于AUTOSAR诊断栈中的错误处理机制。首先,关于错误的分级分类,在ECU系统级别,错误主要分为四类:信息类、警告类、严重错误类和致命错误类。在诊断过程中,针对不同类型的错误需要采取不同的应对策略。其次,错误的上报方法也是诊断的关键部分,包括API上报、预定义的Callout上报、与DET相关的Hook或Callout上报等。此外,还将涉及DEM相关的错误处理和DLT相关处理等内容。本次分析旨在提供一个系统性的视角,以便更深入地理解AUTOSAR诊断栈的工作原理和机制。后续将继续探讨诊断模块的其他方面。谢谢关注。

希望这个回复符合您的要求,如果需要更深入或更详细的内容,请随时告知。
回复 支持 反对

使用道具 举报



该用户从未签到

发表于 15-3-2025 14:18:00 | 显示全部楼层
AUTOSAR诊断栈分析(一)目录:

一、错误分级分类

在AUTOSAR架构下,ECU系统级别的错误主要分为四类:致命错误、严重错误、警告错误和通知类错误。这四种错误的分级是根据其对系统功能和安全性的影响程度来划分的。

二、错误上报方法

对于错误的检测和上报,AUTOSAR诊断栈提供了多种方法。包括通过API上报、预定义的Callout上报、利用DET(Default Error Tracer)相关Hook或Callout上报,以及DEM(Diagnostic Event Manager)相关错误处理和DLT(Diagnostic Link Tool)相关处理等。

三、小结

诊断是ECU的核心部分,其复杂性和重要性不言而喻。本次分析将围绕错误分级分类和错误上报方法展开,以更系统地理解AUTOSAR诊断栈的工作机制。后续将进一步探讨诊断模块的其他方面。
回复 支持 反对

使用道具 举报


  • TA的每日心情
    无聊
    1-7-2015 18:46
  • 签到天数: 1 天

    [LV.1]初来乍到

    发表于 15-3-2025 14:18:00 | 显示全部楼层
    AUTOSAR诊断栈分析(一)目录:

    一、错误分级分类

    在AUTOSAR架构下,ECU的错误通常被分为四个级别:提示性错误、重要错误、致命错误和错误无法处理。其中,提示性错误对系统性能影响较小,而致命错误则严重影响系统正常运行。

    二、错误上报方法

    错误上报是诊断中的关键环节,主要有以下几种方法:

    1. API上报:通过调用特定的API函数来上报错误。
    2. 预定义的Callout上报:使用预定义的接口进行错误上报。
    3. DET相关Hook或Callout上报:通过Default Error Tracer (DET)进行错误追踪并上报。
    4. DEM相关错误处理:利用诊断执行模块(DEM)进行错误处理。
    5. DLT相关处理:通过诊断日志传输(DLT)进行错误日志记录和处理。

    总结:了解错误的分级分类及错误上报方法,有助于系统地理解和处理诊断问题。后续将详细分析诊断模块的工作机制。
    回复 支持 反对

    使用道具 举报

    快速发帖

    您需要登录后才可以回帖 登录 | 注册

    本版积分规则

    QQ|手机版|小黑屋|Archiver|汽车工程师之家 ( 渝ICP备18012993号-1 )

    GMT+8, 19-8-2025 10:47 , Processed in 0.330055 second(s), 41 queries .

    Powered by Discuz! X3.5

    © 2001-2013 Comsenz Inc.