Autosar基础——DLT（DiagnosticLogAndTrace）

---

前言

术语名称	解释
SW-C	Software Component的缩写，即软件组件，它是组成应用软件的基本单元
VFB	VFB(Virtual Function Bus)，也就是虚拟功能总线，而RTE是它的具体实现
RTE	运行时环境（RTE）是AUTOSAR ECU体系结构的核心。RTE是AUTOSAR中VFB的接口实现，特定于每个ECU生成的。RTE提供基础的通信服务，支持软件构件间和软件构件到基础软件模块的通信，并提供AUTOSAR软件组件访问基本软件模块（包括OS和通信服务）的服务。
Log and trace message	一条日志和追踪消息里包含所有描述软件中的日志和事件追踪的数据和选项。它们由消息头和有效载荷组成
Dlt User	DLT用户是指产生Dlt消息的源头。它们可以是应用，RTE或者软件模块
Log message	日志消息包含调试信息，如状态变化或值变化。
Trace Message	跟踪消息包含通过VFB传递的信息
FIBEX	现场总线交换格式是一种通用的XML基础描述格式。
ECU ID	ECU ID是一个ECU的名称，由4个8位ASCII字符(如ABS0、COMB)组成
Session	会话是日志或跟踪消息源的逻辑实体。如果一个SW-C /应用程序被实例化多次，则使用具有全局唯一会话ID的每个实例的一个会话。
Session ID	会话ID是日志或跟踪会话的标识号
Application ID	“应用ID”是SW-C / Application的缩写。它标识日志和跟踪消息产生的SW-C /应用程序。
Context ID	上下文ID是用户自定义ID，四个8位ASCII字符组成上下文ID。用于对swc /应用程序生成的日志和跟踪消息进行分组。具有以下使用规则：1. 每个应用ID可以拥有几个上下文ID 2.上下文ID由应用ID进行分组 3. 一个应用ID里的上下文ID必须是唯一的 4. 使用元组“应用程序ID”和“上下文ID”标识日志和跟踪消息的源
Message ID	消息ID是标识信息的ID，信息由消息本身传输。消息ID唯一地标识日志或跟踪消息。它可以用来标识消息的源(在源代码中)，也可以用来描述消息的有效负载。消息ID是在开发或配置时静态固定的。
Log level	日志级别定义了日志消息的严重级别的分类。
Trace status	跟踪状态提供了是否应该发送跟踪消息的信息
Log Channel	一种用于传输Dlt消息的物理通信总线
External client	外部客户端是使用Dlt模块控制、监视和存储ecu提供的日志/跟踪信息的工具。
PDU	Protocol Data Unit，PDU包含SDU和PCI，PCI包含源地址和目标地址信息，SDU是数据信息

---

一、DLT模块的作用

DiagnosticLogAndTrace：主要有记录（log）和追踪(trace)两个功能
记录信息的来源为DET、DEM模块，以及一些SW-Cs的log信息
追踪信息来自RTE

The Dlt module transmits this data via communication busses to make this information visible outside the ECU.
DLT信息通过通信总线（例如CAN、以太网等）被传递出来给关心这些信息的人来处理，此外，可以通过NVM模块来永久保存DLT的更新过滤器设置，这使得ECU能够以期望的级别传输日志/跟踪信息,而不需要在每次ECU启动时从通信总线（通过日志工具）发出明确的设置请求。

DLT模块位于PDUR和RTE之间：

下图描述了如何在通信总线上发送DLT报文的过程

二、DLT记录和追踪哪些信息

2.1 来自DET模块的错误信息

为了可以通过DLT去报告错误，DLT提供了与DET交互的接口，这些接口是可选的。SWC和BSW的错误会通过Det_ReportError报告给DET，然后再通过DET将错误通过Dlt_DetForwardErrorTrace发给DLT模块。

Det的记录报文需要包含以下值：
ApplicationID = “Det”
ContextId = “STD”
MessageID = “0x00000002”
LogLevel = “Error”

ApplicationId：用于识别Log和Trace信息是源于哪个应用/SWC的，由四个8位ASCII字符组成。

Context ID: 在同一个SWC产生的log/trace消息中进行分组识别。每一个Application ID可以对应多个Context ID，对应同一个Application ID的context ID不能相同。一般由四个8 bit ASCII字符表示。

Session ID: 由于SWC是可以有多个instance的，它们共用同一组Application和Context ID, 因此又引入了Session ID来进行区分。AUTOSAR 并没有对SWC进行session ID的定义，在实际使用时，需要定义port defined argument来设置Session ID。

2.2 来自DEM模块的信息

DEM事件同样可以通过DLT发送到车载网络上，DLT提供了与DEM的接口（可选）。
在DEM中，通过EventID来表征这些来自BSW和SWC的事件，这些事件都包含一些信息如DTC，扩展数据记录和冻结帧。DEM通过调用DLT接口Dlt_DemTriggerOnEventStatus来通知DLT这些事件状态变化。DEM会在接口中说明出现变化的事件的EventID，以此DLT会请求此事件的更多信息。
DLT也会在Dlt_DemTriggerOnEventStatus中比较事件新、旧状态是否一致，如果不一致，就会通过Dlt_SendLogMessage发送DLT log信息。

DEM事件的DLT log报文包含以下值：
ApplicationID = “Dem”
ContextId = “STD”
MessageID = “0x00000001”

2.3 来自RTE的信息（VFB Trace）

包括VFB和BSW调度器（SCHEDULER）被用于与SWC的沟通，来生成记录和追踪信息，并周期地调用DLT模块的发送接口。实际上，DLT通过与RTE的接口来记录VFB trace并处理trace数据。这其中DLT作为client去获取server，也就是RTE提供的VFB trace数据。因此，在RTE的配置中有一个参数RteVfbTraceClientPrefix必须要设置为“Dlt”。

三、DLT与软件SWC的交互

SWC通过DLT提供的接口发送log和trace信息，如果用户希望在log level阈值和trace状态发生变化时再去记录这些信息。
SWC提供一个端口去针对上述变化进行通知，这个通知接口是DLT分别为每一个ApplicationId/ContextId单独提供的，这个机制可以避免在上游重复生成log和trace数据而在DLT中去过滤掉它们。

DLT提供一个SessionId的参数，这个参数适用于区别同一个SWC的不同实例所产生的log/trace.因为DLT模块允许SWC的多重实例使用同一个ApplicationId/ContextId元。

四、协议规范（Protocol specification）

4.1 消息格式

对于调试数据和控制信息，只需使用相同的DLT消息格式：（标准报头、可选的扩展报头、payload-有效复杂段）

其中，标准头部和扩展头部都应当是大端（MSB first）。

4.1.1 标准报头

位置	描述	作用
byte 0	HTYP：报头类型	Bit 0: UEH (Use Extended Header) Bit 1: MSBF (Most Significant Byte First) Bit 2: WEID (With ECU ID) Bit 3: WSID (With Session ID) Bit 4: WTMS (With Timestamp) Bit 5-7: VERS (Version Number)
byte 1	MCNT：消息计数器	每次使用Dlt API发送log/trace消息都会+1
byte 2-3	LEN：长度	Dlt消息长度（标准头部+扩展头部+payload）
byte 4-7	ECU：ECU ID	（可选）当前ECU id
byte 8-11	SEID：会话ID	（可选）当前日志信息的来源
byte 12-15	TMSP：时间戳	（可选）时间信息

为了获得一个时间戳，需配置GPT模块

4.1.2 扩展报头

如果标准报头的UEH位设置为“1”，则传输在Dlt扩展报头格式中定义的附件信息。

Dlt扩展报头直接附件在Dlt标准报头字段之后

位置	描述	作用
byte 0	MSIN：消息信息	Bit 0: VERB (Verbose) Bit 1-3: MSTP (Message Type) Bit 4-7: MTIN (Message Type Info）
byte 1	NOAR：参数的数量	VERB=0时，NOAR=0 VERB=1时，VERB代表payload中arguments的个数
byte 2-5	APID：应用程序ID	Application id
byte 6-9	CTID：上下文ID	用户定义的一个id，用来给一个application发送的dlt消息进行分组

其中MSTP和MTIN的关联如图：

4.2 Log等级

DLT message根据需要，设定了以下log level：

用户可以用日志工具通过通信协议栈请求并设置log level – 如果不想这样做，可以在NvM中存储过滤设置，启动时自动读取。

五、Dlt时序图

5.1 DLT 数据消息传输时序图(Transmission of Dlt Data Message)

5.2 设置日志登记过滤器(Set LogLevel Filter)

5.3 缓存溢出(Buffer Overflow)

六、Dlt命令（Dlt commands）

DLT协议指定由唯一的Service ID标识的各种Dlt命令。Dlt命令用于在运行时修改Dlt模块的行为，例如：获取关于当前Dlt配置的信息或更改过滤器设置。

Service ID	Dlt Command Name	Description
0x01	SetLogLevel	设置Log等级
0x02	SetTraceStatus	启用/禁用Trace消息状态
0x03	GetLogInfo	返回已注册SW-Cs的Log等级
0x04	GetDefaultLogLevel	返回通配符的Log等级
0x05	StoreConfiguration	存储当前配置非易失性
0x06	ResetToFactoryDefault	将配置设置回默认值
0x0A	SetMessageFiltering	启用/禁用DLT过滤器
0x11	SetDefaultLogLevel	设置通配符的Log等级
0x12	SetDefaultTraceStatus	启用/禁用通配符的Trace消息
0x15	GetDefaultTraceStatus	获取通配符的当前Trace等级
0x17	GetLogChannelNames	返回Log通道的名称
0x1F	GetTraceStatus	获取当前Trace状态（开./关）
0x20	SetLogChannelAssignment	添加/删除给定的Log通道作为输出路径
0x21	SetLogChannelThreshold	为给定的Log通道设置过滤器阈值
0x22	GetLogChannelThreshold	获取给定Log通道的过滤器阈值
0x23	BufferOverflowNotification	在DLT模块中显示缓冲区溢出

---

七、DLT使用场景

7.1 DLT的通用场景

1. 应用或SW-C产生日志消息
2. 日志消息发送到DLT模块
3. DLT模块将日志消息发送到总线
4. 外部DLT客户端记录日志消息
   

7.2 VFB追踪(tracing of VFB)

1. RTE调用由DLT提供的宏，该宏可以调用DLT应用接口产生追踪消息（trace message）
2. DLT模块发送跟踪消息到DLT通讯模块（黄色模块）
3. DLT通讯模块转发跟踪消息到网络
4. 外部客户端接收并存储跟踪消息

7.3 DLT运行配置

1. 外部dlt客户端发送日志和跟踪等级变更到dlt模块
2. dlt模块根据收到的变更消息改变自己的过滤器设置配置
3. dlt模块通知应用新的日志等级

7.4 dlt模块通知应用新的日志等级

为了减少总线上的运输量，我们可以避免发送通讯总线上的变量元数据。相反，一个外部FIBEX文件保存如何解释有效负载的信息。外部Dlt客户机使用接收到的参数值合并和存储这些元数据。

1. dlt模块以非冗余模式来传送dlt消息
2. dlt模块过滤和产生dlt消息
3. dlt模块发送dlt消息到通讯总线
4. 外部dlt客户端获取外部FIBEX文件里的元信息
5. 外部dlt客户存储合并的消息