DLT

Introduction

Diagnostic Log and Trace is an implementation of logging software. The software implementation is open source provided under the Mozilla Public License 2.0. The specification of the software comes from AUTOSAR, the AUTOSAR DLT 4.0 specification is attached to this wiki page as a PDF.
Diagnostic Log and Trace is integrated into GDP Software Development Environment with the DLT-Viewer ready to run.

Cheatsheet

Overview

DLT is quite easy to use. As an application developer you only need to follow some steps as described in this document.

Initialization:

Link your application against the DLT library
Include the DLT header file
Register your application
Define all contexts
Register all contexts

Now you are ready to write your logs.

Termination:

Unregister all contexts
Unregister application

Link your application to DLT library
If you compile your application with cmake, you have to add the following lines to your CMakeLists.txt;

find_package(PkgConfig) 
pkg_check_modules(DLT REQUIRED automotive-dlt)

and use the variables ${DLT_INCLUDE_DIRS} and ${DLT_LIBRARIES} for the DLT include and library paths.

Include the DLT Header
To use DLT you have to include the DLT header file in each file you want to use DLT.

#include <dlt.h>

Register your application

You have to register your application as early as possible during the initialisation of your application. You have to call the DLT_REGISTER_APP(). It is only allowed to call DLT_REGISTER_APP() once in your application. You have to provide a application id, which size is maximum four charcters long. In this example we use "MAPP". And you can provide also a description for your application, here it is "Test Application for Logging".

int main(int argc, const char* argv[])
    {
      DLT_REGISTER_APP("MAPP","Test Application for Logging");

    }

If your application uses fork(), you may not call DLT_REGISTER_APP before fork(). And fork() should never be called after DLT_REGISTER_APP. This is because of state information and inter process communication channel to daemon would be copied to new process, but threads would be not. If you are not sure where you are calling DLT_REGISTER_APP() the first time, you can initialise the DLT user library by calling the initialisation routine directly.

dlt_user_init();

DLT_REGISTER_APP is asynchronous. It may take some milliseconds to establish the IPC channel. Because of this, you might lose messages if you log immediately after registering. Typically this is not a problem, but may arise especially with simple examples.

Define all contexts

You can create as many contexts as you like. You can declare one or more contexts in a C or CPP file. Each context is only allowed to be declared once. You have to provide a unique variable name for your context.

#include <dlt.h>

    DLT_DECLARE_CONTEXT(myContext1);
    DLT_DECLARE_CONTEXT(myContext2);
    DLT_DECLARE_CONTEXT(myContext3);

If you want to use a context in another C or CPP file, you can import the context by calling

#include <dlt.h>

    DLT_IMPORT_CONTEXT(myContext1);
    DLT_IMPORT_CONTEXT(myContext2);
    DLT_IMPORT_CONTEXT(myContext3);

Register all contexts

After you have registered your application you must register your contexts, early during initialisation of your application. Do not call DLT_REGISTER_CONTEXT() before DLT_REGISTER_APP(). During registration of each context, you must provide a context id, which size is maximum four charcters long. In this example we use "TESX". And you can provide also a description for your context, here it is "Test Context X for Logging".

int main(int argc, const char* argv[])
    {
      DLT_REGISTER_APP("MAPP","Test Application for Logging");

      DLT_REGISTER_CONTEXT(myContext1,"TES1","Test Context 1 for Logging");
      DLT_REGISTER_CONTEXT(myContext2,"TES2","Test Context 2 for Logging");
      DLT_REGISTER_CONTEXT(myContext3,"TES3","Test Context 3 for Logging");

    }

Create your logs

Now you can start creating your logs. Each log command consist of the context, the log level and a variable number of logging parameters.

Log Level

The log level must be one of the following values:

Log level	Description
DLT_LOG_FATAL	fatal system error
DLT_LOG_ERROR	error with impact to correct functionality
DLT_LOG_WARN	warning, correct behaviour could not be ensured
DLT_LOG_INFO	informational (default)
DLT_LOG_DEBUG	debug
DLT_LOG_VERBOSE	highest grade of information

DLT_LOG_FATAL, DLT_LOG_ERROR and DLT_LOG_WARN should be used in your application, when something is going wrong. DLT_LOG_INFO should be used to send the most important information. DLT_LOG_DEBUG and DLT_LOG_VERBOSE should be only used for testing information.
Each context is set by default to DLT_LOG_INFO log level. All log message are send, which use this loglevel or a lower loglevel. If you also want to see DLT_LOG_DEBUG and DLT_LOG_VERBOSE log messages, you have to raise the log level with the DLT viewer.

Logging parameters

The following parameter types can be used. You can add one or more parameters to a single log message. The size of all logging parameters together should not exceed 2kBytes, including the DLT message header.

Type	Description
DLT_STRING(TEXT)	String
DLT_RAW(BUF,LENGTH)	Raw buffer
DLT_INT(VAR)	Integer variable, dependent on platform
DLT_INT16(VAR)	Integer 16 Bit variable
DLT_INT32(VAR)	Integer 32 Bit variable
DLT_INT64(VAR)	Integer 64 bit variable
DLT_UINT(VAR)	Unsigned integer variable
DLT_UINT16(VAR)	Unsigned 16 Bit integer variable
DLT_UINT32(VAR)	Unsigned 32 Bit integer variable
DLT_UINT64(VAR)	Unsigned 64 bit integer variable
DLT_BOOL(VAR)	Boolean variable
DLT_FLOAT32(VAR)	Float 32 Bit variable
DLT_FLOAT64(VAR)	Float 64 Bit variable

Logging command

Here are some examples for complete log messages. The contexts must be registered before.

DLT_LOG(myContext1,DLT_LOG_ERROR,DLT_INT(5),DLT_STRING("This is a error"));
    DLT_LOG(myContext2,DLT_LOG_INFO,DLT_INT(5),DLT_STRING("But this only information"));
    DLT_LOG(myContext3,DLT_LOG_DEBUG,DLT_INT(5),DLT_STRING("But this only information"));

Unregister contexts and applications

Before terminating your application you must unregister all registered contexts and unregister at last your application.

int main(int argc, const char* argv[])
    {
      DLT_REGISTER_APP("MAPP","Test Application for Logging");

      DLT_REGISTER_CONTEXT(myContext1,"TES1","Test Context 1 for Logging");
      DLT_REGISTER_CONTEXT(myContext2,"TES2","Test Context 2 for Logging");
      DLT_REGISTER_CONTEXT(myContext3,"TES3","Test Context 3 for Logging");

      DLT_UNREGISTER_CONTEXT(myContext1);
      DLT_UNREGISTER_CONTEXT(myContext2);
      DLT_UNREGISTER_CONTEXT(myContext3);

      DLT_UNREGISTER_APP();

      return 0;
    }

Example

Finally here is a complete example for using DLT:
dlt_example.c

#include <stdio.h>
    #include <dlt.h>

    DLT_DECLARE_CONTEXT(myContext1);
    DLT_DECLARE_CONTEXT(myContext2);
    DLT_DECLARE_CONTEXT(myContext3);

    int main()
    {
      /* register application */
      DLT_REGISTER_APP("MAPP","Test Application for Logging");

      /* register all contexts */
      DLT_REGISTER_CONTEXT(myContext1,"TES1","Test Context 1 for Logging");
      DLT_REGISTER_CONTEXT(myContext2,"TES2","Test Context 2 for Logging");
      DLT_REGISTER_CONTEXT(myContext3,"TES3","Test Context 3 for Logging");

      /* Write your logs */
      DLT_LOG(myContext1,DLT_LOG_ERROR,DLT_INT(5),DLT_STRING("This is a error"));
      DLT_LOG(myContext2,DLT_LOG_INFO,DLT_INT(5),DLT_STRING("But this only information"));
      DLT_LOG(myContext3,DLT_LOG_DEBUG,DLT_INT(5),DLT_STRING("But this only information"));

      /* Sleep some time to avoid a flaw in dlt-daemon that would eat your messages
         if you deregister while it still processes your registration */
      sleep(3);

      /* unregister your contexts */
      DLT_UNREGISTER_CONTEXT(myContext1);
      DLT_UNREGISTER_CONTEXT(myContext2);
      DLT_UNREGISTER_CONTEXT(myContext3);

      /* unregister your application */
      DLT_UNREGISTER_APP();

      return 0;

    }

CMakeLists.txt

cmake_minimum_required(VERSION 2.6)

    find_package(PkgConfig)
    pkg_check_modules(DLT REQUIRED automotive-dlt)

    include_directories("${DLT_INCLUDE_DIRS}")

    project(DLTexample)
    add_executable(dlt_example dlt_example.c)

    target_link_libraries(dlt_example ${DLT_LIBRARIES})

Build steps

mkdir build
    cd build
    cmake ..
    make

Usage of DLT

Cosmetic DLT_STRING

The DLT module is providing some macros to log data. Please don't add things like " ", " ", " " (spaces) e.c.

DLT_RAW usage

Avoid using DLT_RAW for data that is less or equal to 4 bytes in size. Each time DLT_RAW is used, 2 bytes for the length information is added.
The DLT RAW Frame is constructed like this:

DLT_RAW	Info	Data_Length	Data
	Length	2	XX

Suboptimal solution:

DLT_LOG_ID7(CH_CONTEXT_STATE, DLT_LOG_DEBUG, 59147,
            DLT_CSTRING("ExitOnError: ("),
            DLTRAW((void*)&SELF(sink)->flbockId, 1),
            DLT_CTRING(","),
            DLT_RAW((void*)&SELF(sink)->insId, 1),
            DLT_CSTRING(","),
            DLT_RAW((void*)&SELF(sink)->sinkNr, 1),
            DLT_CSTRING(")"));

This log output will effectively send:

Header of 20 bytes
9 bytes (3 bytes per DLT RAW)

→ Total 29 header bytes

A solution like this is better

DLT_LOG_ID7(CH_CONTEXT_STATE, DLT_LOG_DEBUG, 59147,
            DLT_CSTRING("ExitOnError: ("),
            DLT_UINT8(SELF(sink)->flbockId),
            DLT_CTRING(","),
            DLT_UINT8(SELF(sink)->insId),
            DLT_CSTRING(","),
            DLT_UINT8(SELF(sink)->sinkNr),
            DLT_CSTRING(")"));

This log output will effectively send:

Header of 20 bytes
3 bytes (DLT_UINT8)

→ Total 23 header bytes
→ We freed 6 bytes in one message by using more effective types!

Group DLT log's

Each DLT message has a header which consumes 20 bytes. There for grouping related information can save a lot of resources. Another advantage of grouping necessary information is that if related information is split into multiple messages these messages are not necessarily printed after each other because they can be interrupted by messages of other processes. Please also refer to Combine multipe messages in the trace guideline
A bad example:

DLT_LOG(mycontext1,DLT_LOG_INFO,DLT_CSTRING("Total frames: "), DLT_UINT16(1000));
DLT_LOG(mycontext1,DLT_LOG_INFO,DLT_CSTRING("Sync frames: "), DLT_UINT8(0));
DLT_LOG(mycontext1,DLT_LOG_INFO,DLT_CSTRING("Reem frames: "), DLT_UINT8(0));
DLT_LOG(mycontext1,DLT_LOG_INFO,DLT_CSTRING("Valid frames: "), DLT_UINT16(100));
DLT_LOG(mycontext1,DLT_LOG_INFO,DLT_CSTRING("Urgent frames: "), DLT_UINT8(0));

Output:

Total frames: 1000
Sync frames: 0
Reem frames: 0
Valid frames: 100
Urgent frames: 0

Better to aggregate information like this:

DLT_LOG(mycontext1,DLT_LOG_INFO, DLT_CSTRING("Frame info: ,"),
                                 DLT_CSTRING("total="),DLT_UINT16(1000),DLT_CSTRING(",")
                                 DLT_CSTRING("sync="),DLT_UINT8(0),DLT_CSTRING(",")
                                 DLT_CSTRING("reem="),DLT_UINT8(0),DLT_CSTRING(",")
                                 DLT_CSTRING("valid="),DLT_UINT16(100),DLT_CSTRING(",")
                                 DLT_CSTRING("urgent="),DLT_UINT8(1))

Output:

Frame info: total=1000, sync=0, reem=100, valid=0, urgent=1
In this example 4*20 bytes are just saved because of the header information. Additionally this information is much easier to analyze.

Log structures recommendation

Structuring conditional parts
When you have to log results of conditional cases avoid to add a log just before or just after the conditional part. Merge logs as well as possible.
Suboptimal solution

if (I_res==TRUE)
{
  DLT_LOG(mycontext1,DLT_LOG_INFO, DLT_CSTRING("Verify ABC Signature: Signature Check result ok"));
}
else
{
  DLT_LOG(mycontext1,DLT_LOG_INFO, DLT_CSTRING("Verify ABC Signature: Signature Check result ERROR!"));
}
DLT_LOG(mycontext1,DLT_LOG_INFO, DLT_CSTRING("Result code of ABC Siganture verification: "),
                                 DLT_INT(parameter_ptr->result));

Better solution

if (I_res==TRUE)
{
  DLT_LOG(mycontext1,DLT_LOG_INFO, DLT_CSTRING("Verify ABC Signature: Signature Check result ok, result code: "),
                                   DLT_INT(parameter_ptr->result));
}
else
{
  DLT_LOG(mycontext1,DLT_LOG_ERROR, DLT_CSTRING("Verify ABC Signature: Signature Check result ERROR, result code: "),
                                   DLT_INT(parameter_ptr->result));
}

→ We gained 20 bytes from the header and all information is compactly availiable in one point.

Logging a switch statement

(in a loop)
suboptimal solution

for(i = 0; i < VALUE_4, i++)
{
  switch(i)
  {
   case VALUE_0:
    Base = Value_0;
    /*Do something*/
    DLT_LOG(mycontext9,DLT_LOG_DEBUG,DLT_CSTRING("Checked value 0"));
    break;
   case VALUE_1:
    Base = Value_1;
    /*Do something*/
    DLT_LOG(mycontext9,DLT_LOG_DEBUG,DLT_CSTRING("Checked value 1"));
    break;
   case VALUE_2:
    Base = Value_2;
    /*Do something*/
    DLT_LOG(mycontext9,DLT_LOG_DEBUG,DLT_CSTRING("Checked value 2"));
    break;
   case VALUE_3:
    Base = Value_3;
    /*Do something*/
    DLT_LOG(mycontext9,DLT_LOG_DEBUG,DLT_CSTRING("Checked value 3"));
    break;
   }
}

optimal solution

for(i = 0; i < VALUE_4, i++)
{
  switch(i)
  {
   case VALUE_0:
    Base = Value_0;
    /*Do something*/
    break;
   case VALUE_1:
    Base = Value_1;
    /*Do something*/
    break;
   case VALUE_2:
    Base = Value_2;
    /*Do something*/
    break;
   case VALUE_3:
    Base = Value_3;
    /*Do something*/
    break;
   }
}
DLT_LOG(mycontext9,DLT_LOG_DEBUG,DLT_CSTRING("Checked values 0-3"));

GENIVI DLT Protocol Extensions

AUTOSAR DLT Protocol Standard

The DLT standard used in the GENIVI DLT implementation is based on AUTOSAR DLT Standard.
The GENIVI DLT standard extends the AUTOSAR protocol specification by some extensions and some smaller modifications.
This Specification describes thesse modifications and extensions.

GENIVI Standardised Ids

The following ECU IDs are predefined in GENIVI:

ECU ID	Description
DLTV	These messages are generated by the DLT Viewer
DLOG	These messages are generated by the Data Logger

The following Application IDs are predefined in GENIVI:

Application ID	Description
DLTS	DLT System

Serial Transport Header

Overview

DLT Control Messages Extension

Overview

GENIVI DLT uses some additional control messages, which are not defined in the DLT standard. This chapter describes the additional control messages used in the GENIVI DLT implementation.

Name	Service Id
Connection Info	0xf02
Marker	0xf04
Timezone	0xf03
Unregister Context	0xf01

Unregister Context

Connection Info

Timezone

Marker

Segmented Network Protocol

Overview

The DLT Messages in GENIVI are limited to a message size of 2048 Bytes. If you want to trace bigger Network messages, these message has to be segmented into smaller messages. GENIVI DLT implemnets are segmentation protocol for Network messages

Network Trace API

The following API is used to trace network messages smaller than 2048 Bytes including the DLT message Header. If the message is bigger the message is not send.

DLT_TRACE_NETWORK(CONTEXT,TYPE,HEADERLEN,HEADER,PAYLOADLEN,PAYLOAD)

The following API can be used to trace network messages bigger than 2048 Bytes including the DLT message Header. If the message is bigger than 2048 Byte the message is truncated to the maximum DLT message size.

DLT_TRACE_NETWORK_TRUNCATED(CONTEXT,TYPE,HEADERLEN,HEADER,PAYLOADLEN,PAYLOAD)

The following API can be used to trace network messages bigger than 2048 Bytes including the DLT message Header. If the message is smaller than 2048 Bytes the message is send in a single Network trace message. If it is longer than 2048 Bytes is is segmented into several smaller messages, see segmentation protocol below.

DLT_TRACE_NETWORK_SEGMENTED(CONTEXT,TYPE,HEADERLEN,HEADER,PAYLOADLEN,PAYLOAD)

Network Trace Protocol

For sending network messages the DLT message type network is used as defined in the AUTOSAR DLT standard. Dependent on the size of the network message, the message is send in a single message or segmented into several messages.

Single Network Message
The single network trace message consists of two payload parameters wit the type raw buffer. The first one is the header, the second one is the payload.

No	Parameter	Type	Description
1	Header	Raw Data	The Header block of the network message
2	Payload	Raw Data	The Payload block of the network message

Truncated Network Message
The truncated network message has the folowing message format:

No	Parameter	Type	Description
1	Identifier	String	Identifier of the message with content "NWTR"
2	Header	Raw Data	The Header block of the network message
3	Payload Size	UINT32	The original size of the payload message
4	Truncated Payload	Raw Data	The truncated payload

Segmented Network Message
The following message is send as the first message of a segmented message. This message contains the header of the network message and further information about the whole network message. For each segmented message of a network message the Indentifier must be unique.

No	Parameter	Type	Description
1	Identifier	String	Identifier of the message with content "NWST"
2	Handle	UINT32	Unique handle for each Network message
3	Header	Raw Data	The Header block of the network message
4	Payload Size	UINT32	The original size of the payload message
5	Number of chunks	UINT16	The number of payload chunks to be send
6	Chunk Max Size	UINT16	The size of a single payload chunk, the last chunk can be smaller

The payload of the network message is segmented into several chunks. Each chunk has a fixed size defined in the first message. The last chunk of the message can be smaller. A sequence counter is used for each network message chunk.

No	Parameter	Type	Description
1	Identifier	String	Identifier of the message with content "NWCH"
2	Handle	UINT32	Unique handle for each Network message
3	Sequence number	UINT16	The sequence number of the Chunk starting by zero and increased for each chunk
4	Payload chunk	Raw Data	The payload chunk

A final message terminates the network transport of a segmented network message.

No	Parameter	Type	Description
1	Identifier	String	Identifier of the message with content "NWEN"
2	Handle	UINT32	Unique handle for each Network message

Tracing DBus Protocol

The type variable must be set to the value DLT_NW_TRACE_IPC.
The DBus message data must be send via the the payload parameter. The header parameter can be stay empty. Optionally the DBus message can be split up into Header and Payload block.

DLT Viewer Manual

GENIVI DLT Viewer

Purpose

The DLT viewer tool is needed to be able to decode, view and store DLT messages generated by DLT daemon or other sources. The DLT Viewer tool enables the software developer and the tester of the device to view the log, control and trace information. It is the goal of GENIVI to provide an utility to control and test all features of the DLT daemon component in a simple way. The DLT daemon component and the DLT viewer is based on the AUTOSAR 4.0 standard DLT.

The main purpose of DLT Viewer is:
1.View DLT files

Drag and Drop support
Recent files selection
Temporary files support
Append files
Index cache of already opened DLT files
Default DLT file loading
Open multiple files (v2.10.1)

2.Retrieve DLT messages from target and store in DLT files

Serial connections
TCP/IP connections
Multiple connections in parallel
Autoconnect to targets
Configure log levels and trace status
Store configuration in target
Reset configuration in target
Organise connections in projects

A further extended functionality is(Filter DLT messsages for analysing):

Filter DLT messsages for analysing
Support to selective show only a part of the messages
Complex filter configurations
Save and restore filter configurations
Default filter configuration
Markers to highlight specific messages
Multiple default filter configurations
Filter index cache of already filtered DLT files
Sorting by time (v2.10.1)

We try to keep the GUI simple for an effective and efficient work but to integrate as much as functionality as we need.

DLT Viewer GUI

Graphical User Interface

The screenshot above will give you a quick impression about how the viewer could look. The viewer is based on Qt so there are widgets you could move around and resize how you like. Your settings of position and size of the widgets are stored when you close the viewer so that you have exact the same window when you start at the next time.
To get a better understanding about the DLT viewer parts they will be explained in more detail.

In the window title you can find the absolute path of your project file and the project name. If you start the DLT viewer with no default project file it will create an unnamed project. After the project name you can read the version of the DLT viewer. In any case of contact with the development team, please report the version of the DLT viewer.
The menu consists of

File
Search
Project
Config
DLT
Filter
Plugin
View
Help

. . . which provides the main functionality to the user which will be described later.

The project widget allows you to configure and control the project, load an existing project, save a change configuration to the DLT daemon and do many other stuff. The project is split into three configuration parts.

The Config which contains all connected ECUs/Devices. Each device contains its provided applications. Each application provides its used contexts.
The Plugin part shows the loaded Plugins. The development team provides a Plugin SDK to you. You are able to write your own DLT viewer plugins to decode messages or display a GUI. Here is more information about the Plugin SDK. TBD In the Settings you can select a default project, which is loaded during start-up.
The Filter part configures the Filters and Marker, which are used

show or mark only specific DLT messages.

DLT Message Table

In the DLT Message table you see all DLT messages in the current selected DLT log file. You can scroll through the whole log file. New received DLT messages are written into the DLT log file. If AutoScroll is enabled in the settings the table scroll always to the end, when new DLT messages are received.

Description of the columns:

Index Index shows the number of the DLT message in the DLT log file, the header shows all header parameters
Time Time when the messages was sent.
Timestamp Time since the startup of the HU
Count Cyclical counter, one per context. Can be used to detect lost messages.
Ecuid Name of the sending ECU
Apid Indetifier of the message sender application. Defined by the sender
Ctid Context indentifier of the message sender. Defined by the sender context.
Type Type of the message. Log/Trace
Subtype Trace type, or Log level.
Mode Verbose/Non-Verbose
Args How many arguments are in the payload.
Payload The payload shows all parameters of the log message.

If a filter is configured, you will see only these DLT messages, which match the filter. Remove all filters, if you want to see all messages. If some plugins are configured and a DLT message matches a plugin the decoded information for Header and Payload is displayed. DLT log files can be loaded or saved in the file menu.

DLT Viewer Plugin

Every DLT Viewer Plugin is opened in a widget, if the plugin is enabled and shown. The DLT Viewer Plugin is shown in the screenshot. You can move every widget at a different position. The poition of the widget is restored after restart of the DLT Viewer.

The Footer shows the following information:
The complete filename of the currently opened DLT File
The version numbers of the SW of the target, if the DLT file contains any DLT messages with version - information.
Statistics about received bytes via target connections.

View DLT files

Drag and Drop support
Recent files selection
Temporary files support
Append files
Index cache of already opened DLT files
Default DLT file loading
Open multiple files (v2.10.1)

Retrieve DLT messages from target and store in DLT files

Retrieve DLT messages from target and store in DLT files
Serial connections
TCP/IP connections
Multiple connections in parallel
Autoconnect to targets
Configure log levels and trace status
Store configuration in target
Reset configuration in target
Organise connections in projects

Filter DLT messsages for analysing

Support to selective show only a part of the messages
Complex filter configurations
Save and restore filter configurations
Default filter configuration
Markers to highlight specific messages
Multiple default filter configurations
Filter index cache of already filtered DLT files
Sorting by time (v2.10.1)

Clipboard support

Copy selected DLT messages to clipboard

Export of DLT files in multiple formats

Supported formats

DLT format with selection
ASCII format
CSV format

Select the messages to be exported

All messages
Filtered messages
Marked messages

Searching DLT messages

Step by step search
Search export view
Search by regular expressions

Project Configurations

Control log levels
Organise configurations in projects
Save and Restore projects
Recent projects selction
Select displayed columns
Default project loading
Automatic timezone synchronisation (v2.10.1)

Plugins Configurations

1.Decode plugins to decode messages
2.Viewer plugins to show more detailed information and analyse logs
3.Control plugins to control applications on the target
4.Available plugins

DLT Viewer Plugin
Non Verbose Mode Plugin
Filetransfer Plugin
DLT Statistic Plugin
DLT System Viewer Plugin

Command line support

Silent mode
Loading project
Loading DLT file
Using filter configuration
Export DLT files to ASCII
Execute commands in plugins

Plugins programming guide

Decode plugins to decode messages
Viewer plugins to show more detailed information and analyse logs
Control plugins to control applications on the target
Available plugins
DLT Viewer Plugin
Non Verbose Mode Plugin
Filetransfer Plugin
DLT Statistic Plugin
DLT System Viewer Plugin

参考链接：
https://at.projects.genivi.org/wiki/display/PROJ/Diagnostic+Log+and+Trace

相关阅读:
android 入门-Activity及字体
 android 入门-安装环境
 PS 零基础训练1
txt操作
 C#重绘TabControl
ini操作
 C#编写ActiveX控件
 远程目录和文件判断
 c#一些操作
 c#消息窗体
原文地址：https://www.cnblogs.com/chendeqiang/p/12861648.html

DLT

Introduction

Cheatsheet

Overview

Register your application

Define all contexts

Register all contexts

Create your logs

Log Level

Logging parameters

Logging command

Unregister contexts and applications

Example

Usage of DLT

Cosmetic DLT_STRING

DLT_RAW usage

Group DLT log's

Log structures recommendation

Logging a switch statement

GENIVI DLT Protocol Extensions

AUTOSAR DLT Protocol Standard

GENIVI Standardised Ids

Serial Transport Header

DLT Control Messages Extension

Overview

Unregister Context

Connection Info

Timezone

Marker

Segmented Network Protocol

Overview

Network Trace API

Network Trace Protocol

Tracing DBus Protocol

DLT Viewer Manual

GENIVI DLT Viewer

Purpose

DLT Viewer GUI

Graphical User Interface

Menu and toolbar

Project widget

DLT Message Table

DLT Viewer Plugin

Footer

View DLT files

Retrieve DLT messages from target and store in DLT files

Filter DLT messsages for analysing

Clipboard support

Export of DLT files in multiple formats

Searching DLT messages

Project Configurations

Plugins Configurations

Command line support

Plugins programming guide