标签：declare   rip   second   show   debug   modules   interrupt   widgets   phi   

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:

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.

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 "\n", "\r", " " (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:

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:

The following Application IDs are predefined in GENIVI:

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.

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.

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

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.

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.

A final message terminates the network transport of a segmented 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.

Menu and toolbar

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.

Project widget

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.

Footer

• 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

DLT

标签：declare   rip   second   show   debug   modules   interrupt   widgets   phi   

原文地址：https://www.cnblogs.com/chendeqiang/p/12861648.html