DLTGENIVI项目下的log软件工程
DLT包括:DLT daemon DTL viewer两个子工程。
DLT daemon运行在ECU上,DTLviewer运行在调试PC上。
github地址:dlt-viewer
为了减少总线上的运输量,我们可以避免发送通讯总线上的变量元数据。相反,一个外部FIBEX文件保存如何解释有效负载的信息。外部Dlt客户机使用接收到的参数值合并和存储这些元数据。
DLT消息包含三个部分:标准头、扩展头、有效载荷。如下图
标准头有16个字节大小,分为6个部分。它们之间的名称和顺序如下图所示
扩展头字段是紧跟在标准头后面的,如果标准头中‘UEH’位位1,则表示该DLT消息有扩展头。扩展图的结构如下图所示:
-Byte0:Message Info,该字节的字段非常重要,设计到dlt消息的类型分类,用来区分是日志消息、跟踪消息、网络消息、控制消息。字段结构如下图所示:
VERB为1时表示有效载荷必须按冗余模式传输
MSTP表示DLT的类型,一共分四种:日志消息、跟踪消息、网络消息、控制消息
MTIN表示不同类型DLT消息各自的下级分类
一图胜千言
非冗余模式下的的有效载荷就比较简单,只传输参数值(不需要任何关于它们的元信息),以及其他属性(如参数名称或类型),为了允许在接收到的Dlt消息中正确地分解所包含的参数值,将向有效负载添加专用的message ID。非冗余模式需要外部解析文件,用来解析Message ID通过消息ID和外部描述的组合,以下信息应该是可恢复的:
类型信息:Type Length、Data Type、String Coding 、Variable Info 、Fixed Point
考虑到MCU的处理能力,非冗余模式只传送dlt消息中的非静态数据,而每条dlt消息中的静态数据通过外部解析文件与Message ID进行关联,非冗余模式DLT消息结构如下:
通过下面的例子,我们来看下非静态数据是如何组装,传输和解析的。
假设下面这条日志消息将要传送给外部DLT客户端:
外部文件像ASAM Fibex文件,保存着如何解析有效载荷的信息。应用程序或中间件的软件供应商应提供此描述文件。由于Dlt可以有多个日志或跟踪消息源(多个应用程序或诊断模块),因此可以将提供的描述文件合并到给定ECU的一个文件中。
每个用于描述非详细消息的Fibex描述文件只对应于一个ECU的日志或跟踪消息。这是因为每个ECU的消息id是唯一的。此外,ECU的软件版本号必须由描述文件提供。
原则上,每个日志或跟踪消息都相当于某些网络协议中已知的PDU。在这里,日志或跟踪消息的描述应该等同于Fibex指定的CAN-Frame。来自Extended Header的信息被另外放入FRAME-TYPE xml元素中的xml元素中。非静态数据由PDU和SIGNAL xml元素描述。
从用户的角度来看,日志或跟踪消息有几个参数。这些参数可以是静态文本或非静态变量。只传输非静态变量的数据。为了用所有参数重新组合整个消息,一个FRAME xml元素应该包含一些空的PDU xml元素,这些元素用静态文本表示参数。此文本应置于PDU xml元素的DESC xml元素中。
<fx:FRAME ID="ID_1"> <ho:SHORT-NAME>Dlt Message with ID_1</ho:SHORT-NAME> <fx:BYTE-LENGTH>1</fx:BYTE-LENGTH> <fx:FRAME-TYPE>OTHER</fx:FRAME-TYPE> <fx:PDU-INSTANCES> <fx:PDU-INSTANCE ID="P_1_0"> <fx:PDU-REF ID-REF="PDU_1_0"/> <fx:SEQUENCE-NUMBER>0</fx:SEQUENCE-NUMBER> </fx:PDU-INSTANCE> <fx:PDU-INSTANCE ID="P_1_1"> <fx:PDU-REF ID-REF="PDU_1_1"/> <fx:SEQUENCE-NUMBER>1</fx:SEQUENCE-NUMBER> </fx:PDU-INSTANCE> <fx:PDU-INSTANCE ID="P_1_2"> <fx:PDU-REF ID-REF="PDU_1_2"/> <fx:SEQUENCE-NUMBER>2</fx:SEQUENCE-NUMBER> </fx:PDU-INSTANCE> </fx:PDU-INSTANCES> <fx:MANUFACTURER-EXTENSION> <MESSAGE_TYPE>DLT_TYPE_LOG</MESSAGE_TYPE> <MESSAGE_INFO>DLT_LOG_DEBUG</MESSAGE_INFO> <APPLICATIONID>APPI</APPLICATIONID> <CONTEXTID>CONI</CONTEXTID> <MESSAGE_SOURCE_FILE>demo.c</MESSAGE_SOURCE_FILE> <MESSAGE_LINE_NUMBER>72</MESSAGE_LINE_NUMBER> </fx:MANUFACTURER-EXTENSION> </fx:FRAME>
<!--=============== 1. Parameter ==================-->
<fx:PDU ID="PDU_1_0"> <ho:SHORT-NAME></ho:SHORT-NAME> <ho:DESC>Temperature measurement</ho:DESC> <fx:BYTE-LENGTH>0</fx:BYTE-LENGTH> <fx:PDU-TYPE>OTHER</fx:PDU-TYPE> </fx:PDU>
<!--=============== 2. Parameter ==================-->
<fx:PDU ID="PDU_1_1"> <ho:SHORT-NAME>measurement_point</ho:SHORT-NAME> <fx:BYTE-LENGTH>1</fx:BYTE-LENGTH> <fx:PDU-TYPE>OTHER</fx:PDU-TYPE> <fx:SIGNAL-INSTANCES> <fx:SIGNAL-INSTANCE ID="S_1_0"> <fx:SEQUENCE-NUMBER>0</fx:SEQUENCE-NUMBER> <fx:SIGNAL-REF ID-REF="S_UINT8"/> </fx:SIGNAL-INSTANCE> </fx:SIGNAL-INSTANCES> </fx:PDU>
<!--=============== 3. Parameter ==================-->
<fx:PDU ID="PDU_1_2"> <ho:SHORT-NAME>reading</ho:SHORT-NAME> <fx:BYTE-LENGTH>1</fx:BYTE-LENGTH> <fx:PDU-TYPE>OTHER</fx:PDU-TYPE> <fx:SIGNAL-INSTANCES> <fx:SIGNAL-INSTANCE ID="S_1_0"> <fx:SEQUENCE-NUMBER>0</fx:SEQUENCE-NUMBER> <fx:SIGNAL-REF ID-REF="FLOA32"/> </fx:SIGNAL-INSTANCE> </fx:SIGNAL-INSTANCES> </fx:PDU>
DLT的冗余模式相对于非冗余模式,显而易见,传递的数据更加全面完整,如果ECU的内存和带宽都够,建议使用冗余模式传输DLT消息。
冗余模式下的DLT消息结构如下图所示:
数据负载包含变量的值(即应用程序或中间件的调试信息),它将在通信总线上传输。除了变量值本身之外,还需要提供变量的大小和类型等信息。该信息包含在Type Info字段中。
-Type Info:32位,表示元数据信息。
从上图可以看出,Type Info主要描述“Data payload”类型信息。
介绍了那么多,来个示例解释下自然数据类型参数是如何表示的吧下面这个示例展示了如何在冗余模式VARI置1的情况下,将一个8位无符号整型数据组装起来。
Type Info是描述数据的32位字段。在这个例子中,它定义了变量类型(无符号整数)、它的长度(8位)和描述变量名称和单位的variable Info (VARI)的存在。Variable Info后面跟着两个16位无符号整数,描述变量的Name和Unit的长度。后面跟着两个以空结束的字符串,它们描述了Name和Unit。最后,变量值紧随其后。Data字段的长度是8位。
Type Info字段各个位之间的组合表
下表显示了根据使用的变量类型的强制(标记x)和可选(标记o)设置:
为了识别日志或跟踪消息的来源,需要在Dlt消息中添加一些在源代码中找到位置的信息。因此,Dlt消息中的前两个参数应为:
日志或跟踪消息的第一个参数应该是一个字符串参数,其中字段“Name”(在Variable Info中)包含字符串“source_file”,数据字段包含源文件的URL。
日志或跟踪消息的第二个参数应该是UINT参数(32位),其中字段“Name”(在Variable Info中)包含字符串“line_number”,数据字段包含发送日志或跟踪消息的源文件中的行号。
以下章节将介绍已定义的Dlt命令,包括唯一标识(Service ID)、格式和所需参数。
下面的表格表示DLT支持的服务命令:
建议定义的Dlt命令可以通过接收相应的Dlt控制消息和/或通过单独的C api触发
术语名称 | 解释 |
---|---|
SW-C | Software Component的缩写,即软件组件,它是组成应用软件的基本单元 |
VFB | VFB(Virtual Function Bus),也就是虚拟功能总线,而RTE是它的具体实现 |
RTE | 运行时环境(RTE)是AUTOSAR ECU体系结构的核心。RTE是AUTOSAR中VFB的接口实现,特定于每个ECU生成的。RTE提供基础的通信服务,支持软件构件间和软件构件到基础软件模块的通信,并提供AUTOSAR软件组件访问基本软件模块(包括OS和通信服务)的服务。 |
Metadata | 元数据是关于数据的数据(参考3) |
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是数据信息 |
1.AUTOSAR虚拟功能总线-VFB
2.DLT协议(AutoSAR官方)
3.元数据
版权声明:本站所有资料均为网友推荐收集整理而来,仅供学习和研究交流使用。
工作时间:8:00-18:00
客服电话
电子邮件
admin@qq.com
扫码二维码
获取最新动态