• Stars
    star
    371
  • Rank 115,103 (Top 3 %)
  • Language
    C
  • License
    Mozilla Public Li...
  • Created about 8 years ago
  • Updated 3 months ago

Reviews

There are no reviews yet. Be the first to send feedback to the community and the maintainers!

Repository Details

Diagnostic Log and Trace.

Diagnostic Log and Trace

Status: Build Status CodeQL

Diagnostic Log and Trace

Welcome to GENIVI Diagnostic Log and Trace (DLT). If you are familiar with DLT and want to know what's new, check the Release Notes.

New to DLT? Great! Welcome aboard. We prepared a brief overview for you as well as some information on how to get started immediately. After you made yourself familiar with the basic mechanics of DLT, you can learn more about advanced concepts and features.

Overview

GENIVI DLT provides a log and trace interface, based on the standardised protocol specified in the AUTOSAR standard 4 DLT. It is used by other GENIVI components but can serve as logging framework for other applications without relation to GENIVI.

The most important terms and parts are depicted in the following figure. Please refer to Glossary for a full overview over DLT-specific terms.

alt text

  • A DLT User essentially is an application that serves its respective (not DLT-related) purpose and produces DLT log messages. It utilizes the DLT library to craft and transmit these messages.
  • The DLT Library provides a convenient API to DLT Users (i.e. applications) to create DLT log messages and hand them over to the DLT Daemon. If the latter is not avilable, the library will cache the messages in a ring buffer so they don't get lost immediately.
  • The DLT Daemon is the DLT communication interface of an ECU. It collects and buffers log messages from one or more DLT users running on the ECU and provides them to DLT clients upon their request. The daemon also accepts control messages from the clients to adjust the daemon's or the aplications' behaviour.
  • A DLT Client receives and consumes the log messages from DLT Users by fetching them from DLT Daemons. It may also issue control messages to control the behaviour of a DLT Daemon or its connected DLT Users. A DLT client can even transmit user-defined data to a DLT User through so-calles injection messages.

This is only the simplest of all use cases that you will further pursue in the Get Started section. Once you want to learn more, you will find that the repository contains advanced features utilizing several adaptors and console utilities as well as test applications.

Get Started

In this section, you can learn how to build and install DLT. Then you can choose to run a DLT demo setup or to start by developing your own DLT-featured application.

Build and install

The following packages need to be installed in order to be able to build and install DLT daemon:

  • cmake
  • zlib
  • dbus
  • json-c (only required for dlt-receives extended filtering)

On Ubuntu those dependencies can be installed with the following command:

sudo apt-get install cmake zlib1g-dev libdbus-glib-1-dev
optional: sudo apt-get install libjson-c-dev # in case you want to use dlt-receives extended filtering

Then proceed to download DLT if you haven't already. We recommend cloning the repository, but downloading and extracting a zip-archive is fine as well.

cd /path/to/workspace
git clone https://github.com/GENIVI/dlt-daemon.git

To build and install the DLT daemon, follow these steps:

cd /path/to/workspace/dlt-daemon
mkdir build
cd build
cmake ..
make
optional: sudo make install
optional: sudo ldconfig # in case you executed make install

CMake accepts a plethora of build options to configure the build to suit your needs.

Run a DLT demo

In case you haven't had a look at the brief overview, now would be the perfect occasion to learn about the most important terms and to get an idea where data is buffered. Then go on with our guide on how to set up a DLT demo setup.

Develop your own DLT-featured application

Now that you have seen DLT in action, you probably want to develop your own applications using DLT. You will find everything you need in our "DLT for Application Developers" guide.

A hint: If you want to read the API documentation, you have to build it locally at the moment. The API documentation is generated with doxygen. To build it, run cmake with the -DWITH_DOC=ON option, e.g.:

mkdir build
cd build
cmake -DWITH_DOC=ON ..
make doc

Build DLT debian package

To build the DLT debian package for your own purpose, follow these steps:

dpkg-buildpackage -us -uc

Learn more

Once you got your feet wet with developing your first application, you might want to learn more. Find out about DLT's advanced topics, learn how to configure, control and interface DLT or study its internals by checking out the design specifications.

Advanced Topics

The GENIVI DLT implementation is capable of by far more than to "just" send log message. You will get an overview of advanced features in this section. Follow the links to learn more about the respective concept.

Document Description
Build Options The CMake build system provides a large amount of build options. They let you turn on or off certain features and provide alternative implementation details.
LogStorage The DLT Daemon as well as the DLT libary provide buffers for caching log data during absence of a consumer. However, some use cases require to write large amounts of log message e.g. to mass storages for long term storage or because no other means of exfiltrating the log data is available.
MultiNode A DLT Daemon can run as a gateway to connect multiple passive nodes. Each passive node has its owns DLT Applications and runs its own daemon. The gateway node connects to all of them, collects the logs and routes them to the DLT Client.
Extended Network Trace Normal DLT messages are limited in size. To overcome this limitation the feature network trace message allows the user to send or truncate messages which would not fit into a normal DLT message.
DLT Filetransfer Although not originally designed for this, files can be transmitted over DLT. A corresponding DLT Client (e.g. DLT Viewer) can receive and decode them accordingly.
DLT KPI Valueable status information about the monitored system can be read via DLT as well. The information under /proc of the target system is at your hands easily.
DLT Core Dump Handler This tool collects and extracts debug information then utilize DLT Filetransfer to transfer the information to client.

Configure, Control and Interface

There is still lots to discover about DLT. If you turn on the generation of manpages with the cmake option -DWITH_MAN=ON you can learn how to configure DLT to exactly suit your needs, how to control the behvaiour of running instances and how to interface DLT with existing system through provided adaptors.

The man pages are generated with pandoc, which also needs asciidoc as dependency.

Build manpages (initally or because something changed) with e.g.

mkdir build
cd build
cmake -DWITH_MAN=ON ..
make generate_man
Document Description
Configuration
dlt-daemon(1) How to start DLT-Daemon
dlt.conf(5) Configure the DLT framework to reflect your use case
Control running instances of DLT
dlt-receive(1) Receive DLT messages from daemon and print or store the log messages.
dlt-control(1) Send control messages to daemon.
dlt-logstorage-ctrl(1) Send a trigger to daemon to connect/disconnect certain logstorage device, or send a demand to sync data the internal buffer into logstorage file.
dlt-passive-node-ctrl(1) Send a trigger to daemon to connect/disconnect passive daemon.
Interfacing DLT
dlt-system(1) DLT-System provides a way to directly access system logs via DLT
dlt-system.conf(5) Configure DLT-System
dlt-adaptor-stdin(1) Adaptor for forwarding input from stdin to daemon.
dlt-adaptor-udp(1) Adaptor for forwarding received UDP messages to daemon.
dlt-convert(1) Convert DLT files into human readable format.
dlt-sortbytimestamp(1) Read log messages from DLT file, sort by timestamp, and store them again.
dlt-qnx-system(1) Access system logs in QNX with DLT

Contribution

Start working, best practice is to commit smaller, compilable pieces during the work that makes it easier to handle later on.

If you want to commit your changes, create a Pull Request in Github. Please make sure to follow the Rules for commit messages

Coding Rules

This project is now using clang-format as replacement of uncrustify.

For convenience, any code changes will be harmonized before commit by hooks/pre-commit.

  • Install clang-format

  • Install pre-commit script by:

    cp scripts/pre-commit.sample .git/hooks/pre-commit
  • Configuration: .clang-format

For reference to clang-format, you can check with: Configurator

Known issues

List of open issues can be found on Github

  • DLT library: Usage of dlt_user_log_write_float64() and DLT_FLOAT64() leads to "Illegal instruction (core dumped)" on ARM target.
  • DLT library: Nested calls to DLT_LOG_ ... are not supported, and will lead to a deadlock.
  • For Non linux platforms [eg: QNX] IPC supported is UNIX_SOCKET. For Linux Platforms both IPC FIFO and UNIX_SOCKET are supported

Software/Hardware

Developed and tested with Ubuntu Linux 16 64-bit / Intel PC

License

Full information on the license for this software is available in the "LICENSE" file. Full information on the license for the cityhash code is available in "COPYING" file in src/core_dump_handler/cityhash_c.

Contact

Methner, Michael [email protected], Le Van, Khanh [email protected]

alt text

More Repositories

1

vsomeip

An implementation of Scalable service-Oriented MiddlewarE over IP
C++
1,104
star
2

dlt-viewer

Diagnostic Log and Trace viewing program
C++
424
star
3

vehicle_signal_specification

Vehicle Signal Specification - standardized way to describe automotive data
YAML
319
star
4

capicxx-core-tools

Common API C++ core tools
C++
135
star
5

capicxx-someip-runtime

Common API C++ SOMEIP runtime
C++
110
star
6

capicxx-core-runtime

Common API C++ core runtime
C++
94
star
7

wayland-ivi-extension

Extensions to the Wayland protocol for InVehicle Infotainment
C
80
star
8

capicxx-someip-tools

Common API C++ SOMEIP tooling
Xtend
77
star
9

vss-tools

Software for working with VSS (https://github.com/COVESA/vehicle_signal_specification)
Python
51
star
10

franca_ara_tools

Translation between Franca Interface Description Language and AUTOSAR XML interface description language
Xtend
43
star
11

capicxx-dbus-tools

Common API C++ dbus tooling
C++
32
star
12

iot-event-analytics

IoT Event Analytics is a complex event processing and agent network platform
JavaScript
26
star
13

franca_ara_integration

Franca to ARA interface integration and demo code
C++
25
star
14

vehicle_signal_interface

Library to distribute vehicle signals between components inside a single ECU
C
23
star
15

vehicle_service_catalog

Vehicle Service Catalog (VSC) extends VSS with functional remote procedure call definitions. See also https://github.com/COVESA/ifex
18
star
16

capicxx-dbus-runtime

Common API C++ dbus runtime
C++
17
star
17

vehicle-edge

Vehicle Edge is a software stack, which acts as an interface between vehicle specific data sources and vehicle agnostic applications
JavaScript
16
star
18

vehicle_signal_manager

Vehicle Signal Manager to read, transform, and emit VSS signals based on configurable rules.
Python
15
star
19

ifex

The Interface Exchange Framework. Tools for processing interface/API descriptions in different formats, including the IFEX core format. Some example files are at: https://github.com/COVESA/vehicle_service_catalog.
Python
14
star
20

capicxx-wamp-tools

Common API tooling with WAMP messaging
C++
12
star
21

capicxx-wamp-runtime

Common API runtime with WAMP messaging
C++
10
star
22

aasig_dev_platform

Development platform for AASIG work (shared build setup for Android in an automotive configuration)
Shell
9
star
23

uservices

uServices - Open Vehicle Interfaces
9
star
24

ramses-citymodel-demo

City model (3D-navigation demo) for the RAMSES distributed graphics framework
C++
7
star
25

aasig-vhal-demo

Repository to collect up the parts and configuration of AASIG VHAL work as submodules
C++
6
star
26

ccs-components

Implementation of technology stack components for the Cloud & Connected Services (CCS) Project
Go
6
star
27

android-external-audio-mixing

Investigate the possibilities in a system that offloads audio mixing from Android Automotive to an external system
C
5
star
28

graphql-vss-server-libs

C++
4
star
29

akm

Automotive Knowledge Model
Python
4
star
30

aosp-app-framework-standardizatiion

AOSP App Framework Standardization
4
star
31

cdsp

The Central Data Service Playground.
Dockerfile
4
star
32

vss-graphql

Configuration and software to serve VSS signals from a GraphQL based server
TypeScript
4
star
33

graphql-vss-data-server

C++
3
star
34

android-vehicleplugin-vss-graphql

Java
3
star
35

CCS-arch-demo

Working directory to collect up all parts of the CCS-arch-demo
Makefile
2
star
36

android-vss-authentication-service

Java
2
star
37

aasig_dev_configuration

Build configurations for aasig_dev_platform (different systems/functionality)
Makefile
2
star
38

test-someip-service

C++
2
star
39

ev_charging

EV Charging Expert Group
Makefile
2
star
40

vehicle-information-service-specification

HTML
2
star
41

covesa-aosp-sdk

Kotlin
2
star
42

vss2graphql_schema

Python
2
star
43

commercial-vehicles

Python
2
star
44

test_franca2vss_mapping_layer

1
star
45

aasig_local_manifests

Manifests for different configurations to build in aasig_dev_platform
1
star
46

graphql_schema2cpp_codegen

Python
1
star
47

hierarchical_information_model

CSS
1
star
48

vss-feeder

Component to convert signals from driving simulator or other source to VSS format and feed into an in-vehicle signal database
JavaScript
1
star
49

vsomeip_py

Python module to leverage COVESA / vsomeip stack.
Python
1
star
50

ev_power_optimization

PHP
1
star
51

commercial-vehicle-information-specifications

CSS
1
star