Documentation update

Signed-off-by: Manikandan C <mchockalingam@de.adit-jv.com>
Signed-off-by: Christoph Lipka <clipka@de.adit-jv.com>

12 files changed, 1042 insertions, 373 deletions

diff --git a/INSTALL b/INSTALL
deleted file mode 100644
index de97b24..0000000
--- a/INSTALL
+++ /dev/null
@@ -1,206 +0,0 @@
-Diagnostic Log and Trace  - Installation
-========================================
-Alexander Wenzel <Alexander.AW.Wenzel@bmw.de>
-
-Instructions for installing this software
------------------------------------------
-The following packages need to be installed in order to be able to build and install DLT daemon:
-- cmake
-- zlib
-- dbus
-
-On Ubuntu those dependencies can be installed with the following command:
-- sudo apt-get install cmake zlib1g-dev libdbus-glib-1-dev
-
-To build and install the DLT daemon, follow these steps:
-
-- mkdir build
-- cd build
-- cmake ..
-- make
-- optional: sudo make install
-- optional: sudo ldconfig
-
-Compile options with default values
------------------------------------
-[options="header"]
-|==============================================================================================
-| Option                        | Value          | Comment
-| BUILD_SHARED_LIBS             | ON             | Set to OFF to build static libraries
-| WITH_SYSTEMD                  | OFF            | Set to ON to run CMakeLists.txt in systemd
-| WITH_SYSTEMD_WATCHDOG         | OFF            | Set to ON to use the systemd watchdog in dlt-daemon
-| WITH_SYSTEMD_JOURNAL          | OFF            | Set to ON to use the systemd journal in dlt-system
-| WITH_DOC                      | OFF            | Set to ON to build documentation target
-| WITH_MAN                      | ON             | Set to OFF to skip building of man pages
-| WITH_CHECK_CONFIG_FILE        | OFF            | Set to ON to create a configure file of CheckIncludeFiles and CheckFunctionExists
-| WITH_TESTSCRIPTS              | OFF            | Set to ON to run CMakeLists.txt in test scripts
-| WITH_GPROF                    | OFF            | Set \-pg to compile flags
-| WITH_DLTTEST                  | OFF            | Set to ON to build with modifications to test User-Daemon communication with corrupt messages
-| WITH_DLT_SHM_ENABLE           | OFF            | Set to OFF to use FIFO as IPC from user to daemon
-| WITH_DLT_ADAPTOR              | ON             | Set to ON to build src/adaptor binaries
-| WITH_DLT_CONSOLE              | ON             | Set to ON to build src/console binaries
-| WITH_DLT_EXAMPLES             | ON             | Set to ON to build src/examples binaries
-| WITH_DLT_SYSTEM               | ON             | Set to ON to build src/system binaries
-| WITH_DLT_DBUS                 | ON             | Set to ON to build src/dbus binaries
-| WITH_DLT_TESTS                | ON             | Set to ON to build src/test binaries
-| WITH_DLT_CXX11_EXT            | OFF            | Set to ON to build C++11 extensions
-| WITH_DLT_COREDUMPHANDLER      | OFF            | EXPERIMENTAL! Set to ON to build src/core_dump_handler binaries. EXPERIMENTAL
-| WITH_DLT_LOGSTORAGE_CTRL_UDEV | OFF            | PROTOTYPE! Set to ON to build logstorage control application with udev support
-| WITH_DLT_LOGSTORAGE_CTRL_PROP | OFF            | PROTOTYPE! Set to ON to build logstorage control application with proprietary support
-| WITH_DLT_USE_IPv6             | ON             | Set to ON for IPv6 support
-| WITH_DLT_KPI                  | ON             | Set to ON to build src/kpi binaries
-| CMAKE_INSTALL_PREFIX          | /usr/local     |
-| CMAKE_BUILD_TYPE              | RelWithDebInfo |
-|==============================================================================================
-
-In order to change these options, you can modify these values
-with ccmake, do the appropriate changes in CmakeList.txt or via
-the commandline for cmake
-
-- Change a value with: cmake -D<Variable>=<Value>
-- Example: cmake -DWITH_SYSTEMD=ON -DWITH_SYSTEMD_JOURNAL=ON -DCMAKE_INSTALL_PREFIX=/usr ..
-
-Create Man pages
-----------------
-The man pages are generated and installed during the standard build and install.
-
-After installation they are located in <CMAKE_INSTALL_PREFIX>/share/man.
-
-The man pages are generated with asciidoc.
-If the man pages are changed the following command must be executed.
-
-----
-mkdir build
-cd build
-cmake -DWITH_DOC=ON ..
-make doc-man
-----
-
-The generated man pages overwrite the existing ones.
-
-Create manuals documentation
-----------------------------
-The manuals are generated with asciidoc.
-
-----
-mkdir build
-cd build
-cmake -DWITH_DOC=ON ..
-make doc-manuals
-----
-
-You will find the generated documents in build/doc/manuals.
-
-Create api documentation
-------------------------
-The API documentation is generated with doxygen.
-
-----
-mkdir build
-cd build
-cmake -DWITH_DOC=ON ..
-make doc
-----
-
-You will find the generated documents in build/doc/DOC_DLT.
-
-Generation of systemd unit files
---------------------------------
-DLT provides cmake files to create unit files for systemd. These can be found in the systemd directory.
-In systemd/CMakeLists.txt you can modify some values, e.g. the port for dlt-adaptor-udp.
-By default the generation of unit files with cmake is disabled. Please follow these steps to enable the generation:
-
-* Change into the root directory of DLT-daemon
-* mkdir build
-* cd build
-* cmake -DWITH_SYSTEMD=ON ..
-
-You find the generated unit files in build/systemd. They are installed in ${CMAKE_INSTALL_PREFIX}/lib/systemd/system when make install is run.
-
-Git configuration
------------------
-It is important to set the name of the user and the email of the user for all git instances on the system:
-
-----
-git config --global user.name "Firstname Lastname"
-git config --global user.email "your_email@youremail.com"
-----
-
-If you are behind a proxy you have to set up the Git proxy configuration, e.g.
-
-----
-git config --global http.proxy $http_proxy
-----
-
-Checkout the code from the OSS Git repository.
-
-----
-git clone http://git.projects.genivi.org/dlt-daemon.git
-----
-
-Working on the code & contribution
-----------------------------------
-Get an overview of all branches:
-
-----
-git branch -a
-----
-
-Switch to the branch you want to work on (see versioning scheme, the master is the feature branch) and verify that it has switched.
-
-----
-git checkout <remote branch>
-git branch -a
-----
-
-Best practice is to create a local branch based on the remote branch:
-
-----
-git checkout -b <local branch> <remote branch>
-----
-
-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, send them to the auto-dlt list, you can create a patch like this:
-
-----
-git format-patch -s <remote branch>
-----
-
-This creates a set of patches (one patch per commit) that shall be published via the mailing list. The patches will be discussed, merged & uploaded on the git.
-
-Please do not forget to document your changes:
-- write a manual for new components or adapt manuals to the changes you have made
-- in case you have added a new program please write a man page for it
-- if you have added something to the DLT API please remember to provide Doxygen comments
-
-
-Please add a header to the top of each new source file you provide:
-
-----
-/*
- * @licence app begin@
- * SPDX license identifier: MPL-2.0
- *
- * Copyright (C) 2011-2016, {COPYRIGHT_HOLDER}
- *
- * This file is part of GENIVI Project DLT - Diagnostic Log and Trace.
- *
- * This Source Code Form is subject to the terms of the
- * Mozilla Public License (MPL), v. 2.0.
- * If a copy of the MPL was not distributed with this file,
- * You can obtain one at http://mozilla.org/MPL/2.0/.
- *
- * For further information see http://www.genivi.org/.
- * @licence end@
- */
-
-/*!
- * \author {YOUR NAME <YOUR_EMAIL_ADDRESS>}
- *
- * \copyright Copyright © 2011-2016 {COPYRIGHT_HOLDER}. \n
- * License MPL-2.0: Mozilla Public License version 2.0 http://mozilla.org/MPL/2.0/.
- *
- * \file {FILENAME}
-*/`
-----
diff --git a/README.md b/README.md
index c7ba698..a2f86e6 100644
--- a/README.md
+++ b/README.md
@@ -2,37 +2,134 @@
 
 ## Overview
 This component provides a log and trace interface, based on the
-standardised protocol specified in the AUTOSAR standard 4.0 DLT.
-This software can be used by GENIVI components and other applications as
-logging facility providing
-
-- the DLT shared library
-- the DLT daemon
-- the DLT daemon adaptors
-- the DLT client console utilities
-- the DLT test applications
-- the DLT unit tests
-
-The DLT daemon is the central component in GENIVI, which gathers all
-logs and traces from the DLT user applications. The logs and traces
-can optionally be directly written to a file in the ECU. The DLT daemon
-forwards all logs and traces to a connected DLT client.
-The DLT client can send control messages to the daemon, e.g. to set
-individual log levels of applications and contexts or get the list of
-applications and contexts registered in the DLT daemon.
+standardised protocol specified in the AUTOSAR standard 4.0 DLT.  
+This software can be used by GENIVI components and other applications as logging framework.
+
+DLT basically consists of 3 components:  
+- __DLT Library__: Enables DLT logging for DLT user applications and temporary storage of log messages if daemon isn't available.
+- __DLT Daemon__: Receiving log messages from DLT user applications and temporary storage of log messages if client isn't available. Transmit log messages to DLT Client and response to control messages.
+- __DLT Client__: Receiving and storage of log messages from DLT Daemon into one single trace file and sending control message
+
+![alt text](doc/images/dlt_overview.png "DLT Overview")
+
+Furthermore, the repository contains several adaptors, console utilities as well as test applications.
+
+## Build and install
+
+The following packages need to be installed in order to be able to build and install DLT daemon:
+```
+- cmake
+- zlib
+- dbus
+```
+
+On Ubuntu those dependencies can be installed with the following command:
+`sudo apt-get install cmake zlib1g-dev libdbus-glib-1-dev`
+
+To build and install the DLT daemon, follow these steps:
+
+```
+mkdir build
+cd build
+cmake ..
+make
+optional: sudo make install
+optional: sudo ldconfig`
+```
+
+### Configuration
+
+#### General Options
+ Option | Value | Comment
+ :--- | :--- | :---
+BUILD_SHARED_LIBS | ON | Set to OFF to build static libraries
+DLT_IPC                       |"FIFO"          | Set to either "UNIX_SOCKET" or"FIFO"
+WITH_DLT_USE_IPv6             | ON             | Set to ON for IPv6 support
+WITH_DLT_EXAMPLES             | ON             | Set to ON to build src/examples binaries
+DLT_USER                      | genivi         | Set user for process not run as root
+WITH_CHECK_CONFIG_FILE        | OFF            | Set to ON to create a configure file of CheckIncludeFiles and CheckFunctionExists
+CMAKE_INSTALL_PREFIX          | /usr/local
+CMAKE_BUILD_TYPE              | RelWithDebInfo
+
+
+#### Command Line Tool Options
+ Option | Value | Comment
+ :--- | :--- | :---
+WITH_DLT_ADAPTOR              | ON             | Set to ON to build src/adaptor binaries
+WITH_DLT_CONSOLE              | ON             | Set to ON to build src/console binaries
+WITH_DLT_SYSTEM               | ON             | Set to ON to build src/system binaries
+WITH_DLT_LOGSTORAGE_CTRL_UDEV | OFF            | PROTOTYPE! Set to ON to build
+WITH_DLT_LOGSTORAGE_CTRL_PROP | OFF            | PROTOTYPE! Set to ON to build logstorage control application with proprietary support
+WITH_DLT_KPI                  | ON             | Set to ON to build src/kpi binaries
+
+#### Linux OS Integration Options
+ Option | Value | Comment
+ :--- | :--- | :---
+WITH_SYSTEMD                  | OFF            | Set to ON to run CMakeLists.txt in systemd
+WITH_SYSTEMD_WATCHDOG         | OFF            | Set to ON to use the systemd watchdog in dlt-daemon
+WITH_SYSTEMD_JOURNAL          | OFF            | Set to ON to use the systemd journal in dlt-system
+WITH_DLT_DBUS                 | ON             | Set to ON to build src/dbus binaries
+
+#### Documentation Options
+ Option | Value | Comment
+ :--- | :--- | :---
+WITH_DOC                      | OFF            | Set to ON to build documentation target
+WITH_MAN                      | ON             | Set to OFF to skip building of man pages
+
+#### Test Options
+Option | Value | Comment
+:--- | :--- | :---
+WITH_TESTSCRIPTS              | OFF            | Set to ON to run CMakeLists.txt in test scripts
+WITH_DLT_TESTS                | ON             | Set to ON to build src/test binaries
+WITH_DLTTEST                  | OFF            | Set to ON to build with modifications to test User-Daemon communication with corrupt messages
+WITH_DLT_UNIT_TESTS           | ON             | Set to ON to build unit test binaries
+WITH_GPROF                    | OFF            | Set \-pg to compile flag
+
+#### Experimental Features Options
+Option | Value | Comment
+:--- | :--- | :---
+WITH_DLT_SHM_ENABLE           | OFF            | Set to OFF to use FIFO as IPC from user to daemon
+WITH_DLT_CXX11_EXT            | OFF            | Set to ON to build C++11 extensions
+WITH_DLT_COREDUMPHANDLER      | OFF            | EXPERIMENTAL! Set to ON to build src/core_dump_handler binaries. EXPERIMENTAL
+
+
+In order to change these options, you can modify these values
+with cmake, do the appropriate changes in CmakeList.txt or via
+the commandline for cmake
+
+Change a value with: cmake -D<Variable>=<Value>, E.g.
+```
+cmake .. -DWITH_SYSTEMD=ON -DWITH_SYSTEMD_JOURNAL=ON -DCMAKE_INSTALL_PREFIX=/usr
+```
 
 ## Documentation
-- DLT Release Notes: ReleaseNotes.txt
-- DLT Installation: INSTALL
+Specific documentation can be found in the following files:
+
+- [ReleaseNotes](ReleaseNotes.md)
+- [Glossary](doc/dlt_glossary.md)
+- [For Developers](doc/dlt_for_developers.md)
+- [Logstorage](doc/dlt_offline_logstorage.md)
+- [MultiNode](doc/dlt_multi_node.md)
+
+All text based documentation will be replaced with by Markdown-based documentation for convinient access.
+
+Old documentation (not maintained - will be removed in future releases):
 - DLT User Manual: doc/dlt_user_manual.txt
 - DLT Cheatsheet: doc/dlt_cheatsheet.txt
 - DLT Design Specification: doc/dlt_design_specification.txt
 - DLT Compilation of all documentation: doc/dlt_book.txt
 
-## API Documentation
-See INSTALL regarding doxygen API documentation generation.
+### API Documentation
+The API documentation is generated with _doxygen_.
 
-## Manpages
+```
+mkdir build
+cd build
+cmake -DWITH_DOC=ON ..
+make doc
+```
+
+### Manpages
 - dlt-daemon(1)
 - dlt.conf(5)
 - dlt-system(1)
@@ -46,29 +143,55 @@ See INSTALL regarding doxygen API documentation generation.
 - dlt-cdh (1)       TBD
 - dlt-kpi (1)       TBD
 
+The man pages are generated with _asciidoc_.
+
+If the man pages are changed the following command must be executed.
+
+```
+mkdir build
+cd build
+cmake -DWITH_DOC=ON ..
+make doc-man
+```
+
+The generated man pages overwrite the existing ones.
+
+## 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.
+
+### Coding Rules
+
+Before contributing code, run uncrustify to harmonize code style.
+
+Configuration: util/uncrustify.cfg
+uncrustify version: 0.68_f
+
 ## Known issues
+
+List of open issues can be found on [Github](https://github.com/GENIVI/dlt-daemon/issues)
+
 - 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 Fedora Linux 22 64-bit / Intel PC
+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 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.
 
 ## Source Code
 - https://github.com/GENIVI/dlt-daemon
-- Older (deprecated) repo: http://git.projects.genivi.org/dlt-daemon.git
-
-## Homepage
-https://at.projects.genivi.org/wiki/display/PROJ/Diagnostic+Log+and+Trace
 
 ## Mailinglist
-https://lists.genivi.org/mailman/listinfo/genivi-diagnostic-log-and-trace
+https://lists.genivi.org/mailman/listinfo/genivi-diagnostic-log-and-trace_lists.genivi.org
 
 ## Contact
-Christoph Lipka <clipka@de.adit-jv.com>
+Christoph Lipka <clipka@de.adit-jv.com>  
 Manikandan Chockalingam <Manikandan.Chockalingam@in.bosch.com>
-Alexander Wenzel <Alexander.AW.Wenzel@bmw.de>
+
 
diff --git a/ReleaseNotes.txt b/ReleaseNotes.md
index fdeba35..c3cc30c 100644
--- a/ReleaseNotes.txt
+++ b/ReleaseNotes.md
@@ -1,21 +1,18 @@
-Diagnostic Log and Trace  - Release Notes
-=========================================
-Christoph Lipka <clipka@de.adit-jv.com>
-Manikandan Chockalingam <Manikandan.Chockalingam@in.bosch.com>
-Alexander Wenzel <Alexander.AW.Wenzel@bmw.de>
-
-Version
--------
+# Diagnostic Log and Trace  - Release Notes
+
+Back to [README.md](../README.md)
+
+## Version
+
 2.17.0 STABLE
 
-Changes
--------
+## Changes
 
-2.17.0
+### 2.17.0
   * Fix for initialization of buffer settings in DLT user library.
-  * fix various memory leaks 
+  * fix various memory leaks
   * some-minor-fixes
-  * Minor fixes: corrected typo in CMakeLists.txt - WTIH_DLT_ADAPTOR, removed character from merge 
+  * Minor fixes: corrected typo in CMakeLists.txt - WTIH_DLT_ADAPTOR, removed character from merge
   * Data stuck in receiver buffer when dlt_daemon_user_send_log_level() fails
   * Update dlt_user.h
   * Add short explanation for DLT log level
@@ -23,13 +20,13 @@ Changes
   * journald adaptor: test with sudo privileges
   * cmake: fix unit tests compilation with systemd
   * Input parameter check & Error message modification
-  * Tell cmake to use README.md instead of README to fix doc generation
+  * Tell cmake to use [README.md](README.md) instead of README to fix doc generation
   * dlt-system-process-handling: fix warning
   * dlt_daemon_connection_types: fix build warnings
   * Updated README
   * dlt-adaptor-udp, dlt-adaptor-stdin: implement get of verbosity level from input
   * Added Description in dlt-system.conf
-  * dlt-client: fix dlt_client_cleanup memory handling 
+  * dlt-client: fix dlt_client_cleanup memory handling
   * CMake Option: Trigger segmentation fault in case of FATAL log
   * Daemon connection handling fixes
   * Added Description in dlt-system.conf
@@ -42,7 +39,7 @@ Changes
   * Added missing build steps to INSTALL
   * pkg-config: fix library directory.
 
-2.16.0
+### 2.16.0
   * doc: Documenatation update
   * Systemd-journal-test: Add WITH_DLT_UNIT_TEST flag when building sources
   * Smoketest: Offline Logstorage
@@ -73,7 +70,7 @@ Changes
   * Fix: File name is broken when file is transferred on 64 bit OS.
   * Fix: Memory leak issue in dlt-dbus
   * Add dlt_user_is_logLevel_enabled API
-  * README.md formatting changes
+  * [README.md](README.md) formatting changes
   * Adding GitHub flavored markdown for README.
   * Fixed D-Bus tracing not working anymore
   * Fixed not working default log level.
@@ -102,7 +99,7 @@ Changes
   * DLT_RETURN_USER_BUFFER_FULL is returned when user buffer full
   * Revert truncation of string or raw block
 
-2.15.0
+### 2.15.0
 
   * Fixed bug with truncation of string or raw block
   * Updated man pages and README
@@ -117,12 +114,12 @@ Changes
   * Added option to specify user for non-root processes
   * Added dlt-kpi component to log various KPI information to dlt-daemon
 
-2.14.1
+### 2.14.1
 
   * MultiNode: Reconnection after connection loss
   * Fix injection message handling
 
-2.14.0
+### 2.14.0
 
   * Fix fork()-handler in libdlt
   * Set default log-levels in dlt.conf
@@ -140,7 +137,7 @@ Changes
   * Event handling has been reworked in order to use epoll and restructure the code
   * Fixed include paths in dlt_user_manual.txt and dlt_cheatsheet.txt
 
-2.13.0
+### 2.13.0
 
   * Added core dump handler code
   * Purged all warnings for -Wall -Wextra with gcc 4.9.1
@@ -165,7 +162,7 @@ Changes
   * Fixed file permissions
   * Added offline logstorage implementation which can be used instead of the already available offline trace functionality
 
-2.12.1
+### 2.12.1
 
   * Removed all trailing whitespaces
   * Replaced all tabs with spaces in all files in include folder
@@ -175,7 +172,7 @@ Changes
   * Rework of unit tests
   * Fix installation paths on x86_64 (lib64 instead of lib)
 
-2.12.0
+### 2.12.0
 
    * Added unit and functional tests
    * Fixed copyright doxygen comments
@@ -212,8 +209,7 @@ Changes
    * Added new API to send marker message from application.
    * New Callback function in DLT library, called when log level of context is changed
 
-
-2.11.0
+### 2.11.0
 
    * New macros for Format of Hex and Binary.
    * Enable dbus trace when adaptor starts up.
@@ -228,7 +224,7 @@ Changes
    * Send extended header in non verbose mode by default and add new API to change setting.
    * Make daemon buffer size configurable
 
-2.10.0
+### 2.10.0
 
    * Bug 184 - /tmp/dltpipes directory does not exist before dlt-daemon is started, logging disabled
    * Updated authors information.
@@ -271,7 +267,7 @@ Changes
    * Fix: Systemd Journal Adapter provides corrupted output.
    * Fix: Install Example service file only when example enabled
 
-2.9.1
+### 2.9.1
 
    * Implementation of command line tool dlt-control.
    * Fix file transfer bug.
@@ -297,7 +293,7 @@ Changes
    * Added creation date and a simple hash on the file name for to improve the uniqueness of getFileSerialNumber
    * File Transfer: improved robustness in case of restarted ECU/dlt-system with interrupted transfers
 
-2.9.0
+### 2.9.0
 
    * Changed documentation and man pages into asciidoc format.
    * Increased buffer sizes for DLT user library and DLT daemon
@@ -305,7 +301,7 @@ Changes
    * [GDLT-137]: Automatically try resending of user buffer after FIFO full
    * [GSWD-85]:  Added authors file
 
-2.8.0
+### 2.8.0
 
    * [GDLT-115]: Encapsulate user macros
    * Fix register app and register context was not stored in buffer when FIFO is full. Other controll messages still not saved in buffer.
@@ -313,7 +309,7 @@ Changes
    * Do not register appliction again, if already registered.
    * Fixed filetransfer not checking buffer fill level.
 
-2.7.0
+### 2.7.0
 
    * [GDLT-24] Fixing compiler warnings
    * [GDLT-94] Optional sending periodic software version messages. See man pages for more informations
@@ -323,12 +319,12 @@ Changes
    * [GDLT-90] Optional: systemd watchdog concept in dlt-system and dlt-daemon
    * [GDLT-67] Re-implemented dlt-system. Read full commit message for more information
 
-2.6.2
+### 2.6.2
 
    * [GDLT-89] Fixed daemon doesn't sent the persistent log level
    * [GDLT-88] Fixed wrong initalization order using offline trace function
 
-2.6.1
+### 2.6.1
 
    * Add _GNU_SOURCE Definition to be able to use O_CLOEXEC
    * Added important SEM_FREE in the daemon and closing fd in the filetransfer
@@ -342,7 +338,7 @@ Changes
    * [GDLT-47] Avoid discarding old contexts if no new memory can be allocate
    * [GDLT-69] Fixed bug in dlt-test-multi-process shares context between threads
 
-2.6.0
+### 2.6.0
 
    * [GDLT-75] Use old style directory check on startup
    * [GENDLT-21] Move mcnt from DltContextData to DltContext
@@ -372,11 +368,11 @@ Changes
    * [GDLT-2] zlib based compression for dlt-system
    * Cleaned some warnings generated from removing stale old code
 
-2.5.2
+### 2.5.2
 
    * Change to Mozilla Public License Version 2.0
 
-2.5.1
+### 2.5.1
 
    * Fixed bug with comparinson between signed and unsigned integer and protection for a buffer overflow.
    * Modified library for new test cases to corrupt data - related to the bug fix for testing signed and unsigned integer
@@ -384,7 +380,7 @@ Changes
    * Replaced dlt-test-filetransfer-image.png with an own created image
    * [GENDLT-21] Fixed bug: Message Counter (MCNT) should be increased but is always 0
 
-2.5.0
+### 2.5.0
 
    * [GDLT-53] Man pages installation included
    * .cproject and .project file for Eclipse included
@@ -398,7 +394,7 @@ Changes
    * [GDLT-35] Compile warnings fixed
    * [GSW-137] Wrong include gives error on compailing against dlt fixed
 
-2.4.2
+### 2.4.2
 
    * Added dynamic increasable ringbuffers to user lib and daemon.
    * dlt-system filetransfer now recovers when file is deleted during filetransfer.
@@ -408,60 +404,60 @@ Changes
    * Fixed buffer overflow problem in buffer library.
    * Disabled share memory by default - disabled completely shared memory if not enabled.
 
-2.4.1
+### 2.4.1
 
-    * Added dynamic increasable ringbuffers to user lib and dlt-daemon.
+   * Added dynamic increasable ringbuffers to user lib and dlt-daemon.
     * Created abstraction of shm buffer management.
     * dlt-system filetransfer now recovers when file is deleted during filetransfer.
     * Added check of file size when starting and deleting files during filetransfer.
     * Added check of shm buffer availability when push to shm.
 
-2.4.1
-
-    * Added internal logging facility to stdout, syslog or local file, configurable in configuration file.
-    * Added deamonise and signal handlers to dlt-system.
-    * Added manual pages.
-    * Added new API dlt_check_library_version() function.
-    * Fifo or SHM mode can be changed by compiler switch.
-    * Replaced SHM implementation.
-    * Fixed shared memory problem in DLT library during startup, if application is started before daemon.
-    * Fixed syslog adapter in dlt-system.
-    * Reverted API changes in dlt_register_app() function.
-    * DLT user library does not set the stack size of the receiver thread anymore.
-
-2.4.0
-
-    * New config files /etc/dlt.conf and /etc/dlt-system.conf must be adapted to the needs
-    * New DLT user lib API dlt_get_log_state() to get DLT client state
-    * New DLT user lib API to manage flow control (needed for bulk data logging)
-    * New DLT user lib API dlt_set_log_mode() to enable/disable internal/external trace
-    * New application dlt-system (filtransfer, proc file system logger,syslog udp adapter included)
-    * [GSW-66] File transfer over DLT.
-    * [GSW-43] Performance improvement for bulk data over DLT.
-    * [GSW-61] Replace command line parameter by configuration file
-    * [GSW-13] Support for keep-alive messages as configuration parameter
-    * [GSW-60] Extended offline DLT Trace memory handling.
-    * Removed filter implementation
-	
-2.3.0
-
-    * [GSW-16] Systemd configuration for syslog to DLT dapater
-    * [GSW-62] DLT Library version check
-    * [GSW-28] Directory where persistent data is stored is not configurable
-    * [GSW-59] Statically allocated large array
-    * Added init script for Ubuntu
-    * Optional adding of gprof compile flags
-    * sprintf with float64 fails on ARM platform; disabled this function on QRM platform.
-
-2.2.0
-
-    * Moved build process completely to cmake
-    * Added commandline parameter -u to set ring buffer size
-    * Reduced cpu consumption needed by applications using DLT library
-    * Increased default ringbuffer size to 10024 bytes
-    * Changed delay in receiver routine to 100ms
-
-2.1.0
+### 2.4.1
+
+   * Added internal logging facility to stdout, syslog or local file, configurable in configuration file.
+  * Added deamonise and signal handlers to dlt-system.
+  * Added manual pages.
+  * Added new API dlt_check_library_version() function.
+  * Fifo or SHM mode can be changed by compiler switch.
+  * Replaced SHM implementation.
+  * Fixed shared memory problem in DLT library during startup, if application is started before daemon.
+  * Fixed syslog adapter in dlt-system.
+  * Reverted API changes in dlt_register_app() function.
+  * DLT user library does not set the stack size of the receiver thread anymore.
+
+### 2.4.0
+
+  * New config files /etc/dlt.conf and /etc/dlt-system.conf must be adapted to the needs
+  * New DLT user lib API dlt_get_log_state() to get DLT client state
+  * New DLT user lib API to manage flow control (needed for bulk data logging)
+  * New DLT user lib API dlt_set_log_mode() to enable/disable internal/external trace
+  * New application dlt-system (filtransfer, proc file system logger,syslog udp adapter included)
+  * [GSW-66] File transfer over DLT.
+  * [GSW-43] Performance improvement for bulk data over DLT.
+  * [GSW-61] Replace command line parameter by configuration file
+  * [GSW-13] Support for keep-alive messages as configuration parameter
+  * [GSW-60] Extended offline DLT Trace memory handling.
+  * Removed filter implementation
+
+### 2.3.0
+
+  * [GSW-16] Systemd configuration for syslog to DLT dapater
+  * [GSW-62] DLT Library version check
+  * [GSW-28] Directory where persistent data is stored is not configurable
+  * [GSW-59] Statically allocated large array
+  * Added init script for Ubuntu
+  * Optional adding of gprof compile flags
+  * sprintf with float64 fails on ARM platform; disabled this function on QRM platform.
+
+### 2.2.0
+
+  * Moved build process completely to cmake
+  * Added commandline parameter -u to set ring buffer size
+  * Reduced cpu consumption needed by applications using DLT library
+  * Increased default ringbuffer size to 10024 bytes
+  * Changed delay in receiver routine to 100ms
+
+### 2.1.0
 
  * DLT Viewer (QT)
     * New dlt viewer (QT-based) implementated
@@ -497,7 +493,7 @@ Changes
     * DLT test programs: Fixed minor bug in dlt-test-user, test3f: Wrong counter was used
     * Removed DLT_LOG calls in injection functions due to problems (application hangs)
 
-2.0.5
+### 2.0.5
 
  * DLT viewer:
 	* The default log level is now shown, if already known
@@ -521,7 +517,7 @@ Changes
 		* Unnecessary functions removed
  * General:
 	* Moved definition of struct DltUser from dlt_user_private.h to dlt_user.h
-	* dlt.h includes now dlt_common.h	
+	* dlt.h includes now dlt_common.h
 	* Extended dlt-test-user and dlt-test-client applications
  * DLT daemon/DLT library: Fixed bug in Filter Delete
  * DLT daemon: Fixed bug in dlt daemon which leads to a crash, when starting/stoping application, then sending
@@ -531,7 +527,7 @@ Changes
  * DLT library: Fixed bug in send function
  * DLT viewer: Fixed bug in set default log level
 
-2.0.4
+### 2.0.4
 
  * License has changed from ADRLPD to ADRLRM
  * DLT viewer:
@@ -563,7 +559,7 @@ Changes
  * Added -lrt to package config file
  * Resolved dependency from dlt_client.h to dlt_common.h -> dlt_common.h is now public
 
-2.0.3
+### 2.0.3
 
  * DLT viewer:
 	* Reduced load if idle
@@ -597,7 +593,7 @@ Changes
  * General: Fixed parsing and printing of MOST messages
  * Several small bugs fixed
 
-2.0.2
+### 2.0.2
 
  * DLT viewer:
 	* Showing timestamp
@@ -630,13 +626,12 @@ Changes
 	* Fixed writing and reading of locally created dlt files
 	* Several smaller bugs fixed
 
-2.0.1
+### 2.0.1
 
  * Full support for serial connection between DLT daemon and DLT Viewer
  * Several small bugs fixed in DLT Viewer
 
-2.0.0
+### 2.0.0
 
  * Initial Release of new DLT daemon Version 2 including the new DLT Client DLT Viewer
- * Initial Release
-
+ * Initial Release
\ No newline at end of file
diff --git a/doc/dlt_book.txt b/doc/dlt_book.txt
index 8a2c91e..009bc74 100644
--- a/doc/dlt_book.txt
+++ b/doc/dlt_book.txt
@@ -53,10 +53,6 @@ include::dlt_filetransfer.txt[]
 
 include::dlt_extended_network_trace.txt[]
 
-include::dlt_offline_logstorage.txt[]
-
-include::dlt_multinode.txt[]
-
 include::dlt_kpi.txt[]
 
 include::dlt_cdh.txt[]
@@ -85,10 +81,3 @@ include::dlt-receive.1.txt[]
 include::dlt-logstorage-ctrl.1.txt[]
 
 :leveloffset: 0
-
-Release Notes
--------------
-
-:leveloffset: 2
-
-include::../ReleaseNotes.txt[]
diff --git a/doc/dlt_design_specification.txt b/doc/dlt_design_specification.txt
index 6d1bdf4..5601a57 100644
--- a/doc/dlt_design_specification.txt
+++ b/doc/dlt_design_specification.txt
@@ -42,8 +42,8 @@ The DLT client can send control messages to the daemon, e.g. to set individual l
 The DLT daemon is the central component between the DLT clients and one or more applications using the DLT user library.
 
 ==== Overview
-The DLT daemon communicates with the DLT clients over TCP/IP connections or over a serial line (the message format is specified in the DLT AUTOSAR Standard), with the applications using the DLT user library over named pipes (FIFOs). More details concerning the exchanged user messages and their content can be found in chapter chapter 6.3.
-The main time, the DLT daemon executes a main loop, in which file and socket descriptors are watched (via epoll()). If a message is received, the DLT daemon reacts. Additionally, a thread is implemented, which if enabled sends each second a keep-alive message to all connected DLT clients.
+The DLT daemon communicates with the DLT clients over TCP/IP connections or over a serial line (the message format is specified in the DLT AUTOSAR Standard), with the applications using the DLT user library over named pipes (FIFOs) or UNIX_SOCKET based on compile time configuration. More details concerning the exchanged user messages and their content can be found in chapter chapter 6.3.
+The main time, the DLT daemon executes a main loop, in which file and socket descriptors are watched (via poll()). If a message is received, the DLT daemon reacts. Additionally, a thread is implemented, which if enabled sends each second a keep-alive message to all connected DLT clients.
 Here is a rough schematic, how the DLT daemon is structured:
 
 .DLT Overview
@@ -61,7 +61,7 @@ During initialization of the DLT daemon, the following steps occur:
 ** Setup signal handler
 ** Open DLT output file, if specified
 * After phase 1, the daemon initializes the connection handling:
-** Delete, create and open its own named FIFO /tmp/dlt
+** Delete, create and open its own named FIFO /tmp/dlt or UNIX_SOCKET
 ** Open, bind and listen to TCP socket for incoming connections
 ** Setup and open serial device, if specified
 * Then the daemon enters initialization phase 2:
@@ -77,12 +77,12 @@ During initialization of the DLT daemon, the following steps occur:
 ==== Main loop
 In the main loop, the following things occur:
 
-* Wait for event on the incoming named pipe, the TCP connections (the one connection for new connections, and all TCP connections from clients), and possibly on the serial device, via epoll() call.
+* Wait for event on the incoming named pipe or socket, the TCP connections (the one connection for new connections, and all TCP connections from clients), and possibly on the serial device, via poll() call.
 * Distinguish from which socket/file descriptor the connection came, and handle them:
 ** Event from TCP server socket (New DLT client to DLT daemon):
 *** Create new TCP connection
 *** If the newly created connection is the first TCP connection, send all log messages already stored in ring buffer to DLT client.
-** Event from incoming named pipe (DLT user library to DLT daemon):
+** Event from incoming named pipe or unix socket(DLT user library to DLT daemon):
 *** Use dlt receiver to read data
 *** As long as there are DLT messages available in received data:
 **** Handle user message:
@@ -184,7 +184,7 @@ During receiver thread within the DLT user library checks for newly received mes
 
 ==== Overflow handling
 
-If the named pipe of the DLT daemon is full, an overflow flag is set and the message stored in a ring buffer. The next time, a message could be send to the DLT daemon, an overflow message is send first, then the contents of the ring buffer. If sending of this message was possible, the overflow flag is reset.
+If the named pipe/socket of the DLT daemon is full, an overflow flag is set and the message stored in a ring buffer. The next time, a message could be send to the DLT daemon, an overflow message is send first, then the contents of the ring buffer. If sending of this message was possible, the overflow flag is reset.
 
 ==== Send log message
 
@@ -209,7 +209,7 @@ During sending of a log message, the following things occur:
 ** Check for overflow flag and try to send overflow message.
 ** Try to send message to DLT daemon, and check for return values. This can be:
 *** data could not be written
-*** handle not open or pipe error
+*** handle not open or pipe/socket error
 *** other error condition
 *** no error, all right
 ** If sending failed, put this message in the ring buffer for later sending.
@@ -245,9 +245,9 @@ During registration of a callback function for a injection message, the followin
 
 === Communication between DLT daemon and DLT user library
 
-The communication mechanism used between DLT daemon and DLT user library are named pipes (FIFOs).
-During startup of the DLT daemon, the DLT daemon creates and opens one named pipe called /tmp/dlt. If a DLT user application using the DLT user library wants to send something to the DLT daemon this pipe is used.
-During startup of the DLT user application using the DLT user library, it creates and opens a named pipe called /tmp/dlt<PID>, where <PID> is the process id of the DLT user application. If the DLT daemon wants to send something to the DLT user application, this specific named pipe is used.
+The communication mechanism(IPC) used between DLT daemon and DLT user library are named pipes (FIFOs) or UNIX_SOCKETS (based on compile time configuration).
+During startup of the DLT daemon, the DLT daemon creates and opens the IPC on configured path. If a DLT user application using the DLT user library wants to send something to the DLT daemon this IPC is used.
+During startup of the DLT user application using the DLT user library, it creates and opens the same IPC (a named pipe called /tmp/dlt<PID>, where <PID> is the process id of the DLT user application or an UNIX_SOCKET). If the DLT daemon wants to send something to the DLT user application, this IPC is used.
 The exchanged messages are described in the chapter 7.1.
 
 === Place of message creation
@@ -516,8 +516,8 @@ The following table shows a top level view of the available Git repositories:
 [options="header"]
 |==============================================================================================
 | Directory | Description
-| dlt | | DLT Daemon and Library implementation; command line utilities, examples and test programs
-| dlt_viewer | | DLT Client GUI (DLT Viewer): QT based implementation
+| dlt | DLT Daemon and Library implementation; command line utilities, examples and test programs
+| dlt_viewer | DLT Client GUI (DLT Viewer): QT based implementation
 |==============================================================================================
 
 As this document has the focus on the DLT Daemon and the DLT user library, only the "dlt" directory is introduced in more detail:
@@ -525,19 +525,19 @@ As this document has the focus on the DLT Daemon and the DLT user library, only
 [options="header"]
 |==============================================================================================
 | Directory | Description
-| doc | | Documentation
-| include | | Include files, installed on target
-| package | | Packaging support files
-| src | | Source Code
-| src | shared | Shared source code (between DLT daemon and DLT user library)
-| src | adaptor | Adaptors to DLT daemon:dlt-adaptor-stdin (for connection over stdin) dlt-adaptor-udp (for connection over UDP)
-| src | console | Console utilities: dlt-receive, dlt-convert, and dlt-sortbytimestamp
-| src | daemon | DLT Daemon
-| src | example | Examples for usage of the DLT user library:dlt-example-user (Macro IF) anddlt-example-user-func (Function IF) andwintestclient (MS Windows based test client)
-| src | lib | DLT library functions
-| src | tests | Test programs:dlt-test-client and dlt-test-user for automatic tests, dlt-test-stress for stress tests, dlt-test-internal for internal tests
-| src | winclientlib | MS Windows implementation of a client library
-| testscripts | | Several supporting scripts
+| doc | Documentation
+| include | Include files, installed on target
+| package | Packaging support files
+| src | Source Code
+| src/shared | Shared source code (between DLT daemon and DLT user library)
+| src/adaptor | Adaptors to DLT daemon:dlt-adaptor-stdin (for connection over stdin) dlt-adaptor-udp (for connection over UDP)
+| src/console | Console utilities: dlt-receive, dlt-convert, and dlt-sortbytimestamp
+| src/daemon | DLT Daemon
+| src/example | Examples for usage of the DLT user library:dlt-example-user (Macro IF) anddlt-example-user-func (Function IF) andwintestclient (MS Windows based test client)
+| src/lib | DLT library functions
+| src/tests | Test programs:dlt-test-client and dlt-test-user for automatic tests, dlt-test-stress for stress tests, dlt-test-internal for internal tests
+| src/winclientlib | MS Windows implementation of a client library
+| testscripts | Several supporting scripts
 |==============================================================================================
 
 The DLT daemon implementation uses the following files, besides DLT functions from files from the shared directory:
@@ -636,7 +636,7 @@ The following important structures are used in the DLT Daemon and DLT User Libra
 ** C-only implementation for the DLT daemon and the DLT user library
 ** Implementation of common functions, which can be used in a command line utility as well as in an Graphical UI
 ** Implementation of C+\+ like classes in C, see dlt_common.c and dlt_common.h
-* The current implementation of the DLT daemon and DLT user library is only tested with gcc under Ubuntu 9.10/10.04 on Intel HW.
+* The current implementation of the DLT daemon and DLT user library is only tested with gcc under Ubuntu 16.04 on Intel HW.
 * It is assumed that packed structs are always stored in memory in the order specified within the packed struct.
 * The implementation is multithread safe.
 * Initialize DLT application and contexts, then forking and using the forked process, will lead to unclear behavior (or in worst case to a crash), as the forked process uses another process id as the parent process. Instead, initialize the DLT application and contexts in the forked process.
diff --git a/doc/dlt_for_developers.md b/doc/dlt_for_developers.md
new file mode 100644
index 0000000..005bb8c
--- /dev/null
+++ b/doc/dlt_for_developers.md
@@ -0,0 +1,426 @@
+# How to DLT for developers
+
+Table of Contents
+1. [Summary](#Summary)
+2. [Example Application](#DLT-Example-Application)
+3. [General Rules for Logging](#General-Rules-for-Logging)
+4. [The use of Log Levels](#The-use-of-Log-Levels)
+5. [DLT Library Runtime Configuration](#DLT-Library-Runtime-Configuration)
+6. [DLT API Usage](#DLT-API-Usage)
+7. [DLT injection messages](#DLT-Injection-Messages)
+8.1	Log level changed callback	21
+9	Build DLT from source	21
+
+ 
+
+## DLT Example Application
+This example gives an overview of DLT usage inside an application by using a minimal code example. Detailed information about the API can be found later in this document.
+
+```
+#include <dlt/dlt.h>
+
+DLT_DECLARE_CONTEXT(ctx); /* declare context */
+
+int main()
+{
+	DLT_REGISTER_APP("TAPP", "Test Application for Logging");
+
+	DLT_REGISTER_CONTEXT(ctx, "TES1", "Test Context for Logging");
+
+	/* … */
+
+	DLT_LOG(ctx, DLT_LOG_ERROR, DLT_CSTRING("This is an error"));
+
+	/* … */
+
+	DLT_UNREGISTER_CONTEXT(ctx);
+	DLT_UNREGISTER_APP();
+	return 0;
+}
+```
+
+DLT is quite easy to use. The first thing a developer has to do is to include the dlt header file. DLT contexts can be statically declared using the macro shown in next line.  
+Firstly, a DLT application has to be registered inside the main function. For this, an application identifier APID and application description has to be specified. Afterwards, one or more DLT contexts could be specified.  
+To log messages in verbose mode, the DLT_LOG macro can be used. As parameter, the logging context, the log level and a variable list of parameters have to be specified. DLT requires each parameter to be strongly typed using DLT type macros. In this example, DLT_CSTRING  is used to specify a constant string.
+On application cleanup, all DLT contexts, as well as the DLT application have to be unregistered.  
+
+## General Rules for Logging
+### Be Smart
+Before implementing logging in code one should take a second to think about a concept first. Often strategic places in the software can be used as a central place for logging. Such places are often interfaces to other SW components. Use the solution with the smallest impact. Avoid logging the “good cases” but log e.g. in your error handling sections – you will need error handling anyway. In case an error occurred more logs don’t matter as long as your regular code produces little logs. Keep in mind that tracing comes with a price tag – you are working in an embedded environment where CPU, memory and Bandwidth are sparse.
+### Avoid high frequency outputs
+Certain events occur very often in a system – some of them dozens of times per second. In such a case do not implement logging for each occurrence. One example is the screen frame rate. Instead of printing a log for each frame rate aggregate the information and print an average once every five seconds or – even better – report once a second if the frame rate is below a critical value.
+### Combine multiple messages
+Please always consider that each Log message creates a certain overhead. In case of DLT as the way of logging each has a header of 20 bytes. Therefore please aggregate information. In this way all necessary information is always combined.
+Please always use a human readable format; use identifiers for the different values, be consistent with separators. This helps to work with the data, especially when log messages are processed by scripts.
+Such scripts often use regular expressions – make the job easier!
+For example don’t write log entries like this:
+
+```
+Total frames:  1000
+Sync frames:   0
+Reem frames:   0
+Valid frames:  100
+Urgent frames: 0
+```
+
+Better aggregate Information into a single message:
+```
+Frame info: total=1000, sync=0, reem=1000, valid=0, urgent=1
+```
+
+### Do not use ASCII-art
+Information should be “on your fingertips”. Logging is a tool to ease crushing bugs, not to win a computer art contest. → Don’t use ASCII Art!
+
+### Do not create charts using ASCII
+Charts can be a great help to visualize what is going on in the system. This type can be nicely done by a trace analysis or in case of usage of the DLT Viewer, in a Plugin. It certainly should always be done in a post processing step. Doing this on the target is a waste of resources.
+
+### Avoid tracing in loops
+Bad example:
+```
+for(int index=0; index<MAX; index++)
+{
+  LOG("Loop: %d", index);
+  /* ... */
+}
+```
+Good example:
+```
+for(int index=0; index<MAX; index++)
+{
+  /* ... */
+}
+
+LOG("Loop count: %d", index);
+```
+
+### Other do and avoids
+Topic | Description
+--- | ---
+Avoid timestamps | Do not include a timestamp in your log messages. In case of DLT the logging system itself already provides a timestamp.
+Avoid high logging at startup | Especially the system startup is always a high load situation. Please avoid to write a log of log outputs during the startup because the helps to avoid an overload situation and speeds up the startup.
+Remove old log messages | If certain long log messages are not necessary anymore, because the problem has been resolved, please remove them from your code.
+Do use constant separators | Use consistent field separators and delimiters between different variables and information in order to facilitate automatic log analysis.
+Do use proper logs | The logs should contain the information that you require to identify a problem. If you find yourself producing a new binary to identify a problem every time somebody reports an error something may be wrong.
+Avoid eye catchers | Please don’t use custom highlighting for marking the messages which are important for you. The best way is to write a clear identifier in the front of your trace message. This can than (in the viewer) be easily used for filter sets or even for coloring.
+An example for messages informing about the frame rate could be: Frame rate: low: 12, high: 34, avr: 28
+Do not log to the console | Do not use _printf()_ or similar statements to trace to the console. Such behavior can make it problematic to work e.g. with the serial console or even might slow down the execution of the program. In a vehicle based test system the console messages are not recorded and will not help you.
+Do  “macrotize” dlt macros | Don’t write your own macros to capsulate DLT macros.
+
+## The use of Log Levels
+###	Overview
+The following log levels are available in DLT:
+
+Log Level | Description
+--- | ---
+DLT_LOG_FATAL | Fatal system errors, should be very rare
+DLT_LOG_ERROR | Error with impact on correct functionality
+DLT_LOG_WARN | Warning if correct behavior cannot not be ensured
+DLT_LOG_INFO | Informational, providing high level understanding
+DLT_LOG_DEBUG | Detailed debug information for programmers
+DLT_LOG_VERBOSE | Verbose debug information for programmers
+
+Please be aware the the default Log Level is set to INFO: This means message which are logged in INFO, WARN, ERROR and FATAL will logged.  
+Hint: The default Log Level can be changed by setting an environment variable (see DLT Library - runtime configuration).
+
+### What to log at FATAL level
+Fatal errors are the most serious error and should be very rare. They are, for example:
+-	Errors that cause the whole system to fail
+-	A corrupted boot environment which prevents system boot
+-	A critical hardware component is missing, failing or is preventing start-up.
+-	When your software/process/component exits due to a fatal error. Log the EXIT and the reason.
+-	Failure of a major critical component to start
+
+### What to log at ERROR level
+This level is reserved for errors which impact the correct functionality of the system or its components. Errors related to connected customer devices such as phones should be logged at INFO level. Error level logs may be:
+-	A non-critical component is failing or cannot be found
+-	A system component is crashing
+-	A system essential file can’t be read or written
+-	Detection of corrupted network messages, files, etc. when these impact correct
+-	Some major functionality could not be provided (e.g. the route in the navigation could not be calculated)
+-	When your software/process/component exits due to an error. Log the EXIT and reason
+
+### What to log at WARNING level
+This level must be used for problems where a correct behavior cannot be ensured, i.e. problems that could affect the correct functionality of the system or its components. Warnings related to connected customer devices such as phones must be logged at INFO level. Examples for warning log messages could be: DLT dropping logs
+-	No disk space available for core dump
+-	Audio stream packet dropped
+-	If a process of calculation takes longer than the time allowed in specification e.g. Calculation of route in the navigation takes longer than allowed
+
+### What to log at INFO level
+This level is reserved for key information and high-level events which are not errors or warnings of the system itself or of connected consumer devices.
+-	Start and non-error related stop of software components. Include version information in start log.
+-	Detection of key hardware components. Include key HW information in log.
+-	Customer device connected. Include key device and media info.
+-	Customer device detached or connection lost.
+-	Failure to connect to customer device. Include reason
+-	Corrupted disk, song, photo, etc. on customer device.
+-	Key system/HW information at start-up
+-	Information needed for reproducing and understanding user activity
+-	Information for reproducing the environment (Large volume data such as GPS traces should be logged at a reasonable rate. Especially with very frequent logs it should be taken care of that no redundancy occurs)
+-	Key information used for KPI (Key performance index) reporting
+
+### What to log at DEBUG level
+This level should be used for debug information that can help developers debug the functionality of their software. For example:
+-	Information about entering and exiting major procedures
+-	Values of key variables, but not dumps of arrays and large number of variables
+-	Information about events received
+-	Network connection information
+-	Debug relevant information about hardware
+
+### What to log at VERBOSE level
+This level is the most detailed level and should be used for in depth debug information that can help developers debug the functionality of their software. For example:
+-	Detailed trace information
+-	Dumps of a large number of variables, dumps of arrays and structures
+-	Detailed information about events received, even events that happen very frequently
+-	Detailed network connection information
+-	Detailed hardware information
+-	Information about loops and iterations
+
+## DLT Library Runtime Configuration
+The DLT library can be configured at runtime – globally or for a specific process – by setting different environment variables. In the following, these environment variables are described:
+###	Initial Log level
+The default log level of DLT User library is DLT_LOG_INFO. This can be changed using a DLT client application (e.g. DLT Viewer). But there might be situations where DEBUG or VERBOSE messages are needed before the DLT Daemon updated the user library.  
+In this case DLT_INITIAL_LOG_LEVEL can be exported. Using this environment variable, the user can specify log level for contexts that will be used on library startup.  
+For example, an application “EXA1” has two contexts “CON1” and “CON2”. For “CON1” log level DEBUG and for “CON2” log level VERBOSE shall be used. The following has to be exported to configure the library:
+```
+ export DLT_INITIAL_LOG_LEVEL=”EXA1:CON1:5;EXA1:CON2:6”
+```
+
+### Local print mode
+Sometimes it might be useful to print DLT messages for debugging directly to console. To force the library to do so, the following environment variable can be exported:
+```
+export DLT_LOCAL_PRINT_MODE=FORCE_ON
+```
+###	Library buffer size
+The DLT library contains a message buffer in case the DLT Daemon is not started yet or the connection to DLT Daemon is temporarily lost. The buffer is allocated while library initialization with a minimum size. If more messages need to be stored, the buffer grows in defined steps up to a maximum size. In case messages are flushed to DLT Daemon, the buffer is reduced to its minimal size. The default values and the environment variable names to set these values are described below:
+
+|	| Default value [in bytes] |	Environment variable name
+--- | --- | ---
+Minimal size | 50000 | DLT_USER_BUFFER_MIN
+Maximal size | 500000 | DLT_USER_BUFFER_MAX
+Step size | 50000 | DLT_USER_BUFFER_STEP
+
+For example, to limit the maximum buffer size to 250k bytes, the following can be exported:
+```
+export DLT_USER_BUFFER_MAX=250000
+```
+
+## DLT API Usage
+
+### Register application
+**Important note**: If the application uses _fork()_, DLT_REGISTER_APP may not be called before fork().  
+The DLT application has to be registered as early as possible during the initialization of the application by calling DLT_REGISTER_APP(). It is only allowed to call DLT_REGISTER_APP() once per application. An application id (maximum four characters) has to be specified and must be unique within an ECU. In this example "MAPP" is used. And also a description for the application can be specified, here it is "Test Application for Logging".
+```
+int main(int argc, const char* argv[])
+{
+    DLT_REGISTER_APP("MAPP","Test Application for Logging");
+}
+```
+
+DLT_REGISTER_APP is asynchronous. It may take some milliseconds to establish the IPC channel. Because of this, messages might be lost if logs are emitted immediately after registering. Typically this is not a problem, but may arise especially with simple examples.
+
+### Define and register all logging contexts
+As many contexts as needed can be defined. These contexts can be declared as contexts in different C or CPP files. But each context is only allowed to be declared once. Therefore a unique variable name for each context has to be used.
+```
+DLT_DECLARE_CONTEXT(myContext1);
+DLT_DECLARE_CONTEXT(myContext2);
+DLT_DECLARE_CONTEXT(myContext3);
+```
+If contexts from another C or CPP file shall be used, these contexts can be imported by calling:
+```
+DLT_IMPORT_CONTEXT(myContext1);
+DLT_IMPORT_CONTEXT(myContext2);
+DLT_IMPORT_CONTEXT(myContext3);
+```
+After the application is registered and contexts are declared, contexts need to be registered early during initialization of the application. DLT_REGISTER_CONTEXT() shall not be called before DLT_REGISTER_APP().
+During registration of each context, a context id must be provided (maximum four characters long). In this example "TESX" is used. Also a description for the context can be provided; here it is "Test Context X for Logging". A context can also be registered with a predefined Log Level and Trace Status by using the Macro DLT_REGISTER_CONTEXT_LL_TS. The third context is registered using this method.
+```
+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_LL_TS(myContext3, "TES3","Test Context 3 for Logging", DLT_LOG_DEBUG, DLT_TRACE_STATUS_OFF);
+}
+```
+
+### Unregister contexts and application
+Before terminating the application registered contexts and at last the application need to be unregistered.
+```
+int main(int argc, const char* argv[])
+{
+/* business logic */
+
+  DLT_UNREGISTER_CONTEXT(myContext1);
+  DLT_UNREGISTER_CONTEXT(myContext2);
+  DLT_UNREGISTER_CONTEXT(myContext3);
+
+  DLT_UNREGISTER_APP();
+
+  return 0;
+}
+```
+
+### Logging command
+DLT provides functions and macros for logging, whereas the interface for Verbose and Non-Verbose differs. The following table shows an example of all 4 types for logging using a constant string and an integer.
+
+#### Verbose vs. Non-Verbose API
+The following table shows an example of all 4 types for logging e.g. a string and an integer.
+
+##### MACRO
+###### Verbose
+```DLT_LOG(ctx, DLT_LOG_INFO, DLT_STRING("ID: "), DLT_UINT32(123));```
+
+###### Non-Verbose
+
+```
+DLT_LOG_ID(ctx, DLT_LOG_INFO, 42, /* unique message ID */ DLT_STRING("ID: "), DLT_UINT32(123));
+```
+
+##### Function
+
+###### Verbose
+
+```
+if (dlt_user_log_write_start(&ctx, &ctxdata, DLT_LOG_INFO) > 0) {
+    dlt_user_log_write_string(&myctxdata, "ID: ");
+    dlt_user_log_write_uint32(&myctxdata, 123);
+    dlt_user_log_write_finish(&myctxdata);
+}
+```
+
+###### Non-Verbose
+
+```
+if (dlt_user_log_write_start_id(&ctx, &ctxdata, DLT_LOG_INFO, 42) > 0) {
+    dlt_user_log_write_string(&myctxdata, "ID: ");
+    dlt_user_log_write_uint32(&myctxdata, 123);
+    dlt_user_log_write_finish(&myctxdata);
+}
+```
+
+Drawback of that solution is that the developer has to decide during development if Verbose or Non-Verbose mode shall be used and the code most likely ends up as written in the dlt-example-user application  (line 373):
+
+```
+if (gflag) {
+    /* Non-verbose mode */
+    DLT_LOG_ID(ctx, DLT_LOG_INFO, 42 /* unique msg id*/,
+    DLT_INT(num), DLT_STRING(text));
+}
+else {
+    /* Verbose mode */
+    DLT_LOG(ctx, DLT_LOG_INFO, DLT_INT(num), DLT_STRING(text));
+}
+```
+
+##### Switching Verbose and Non-Verbose
+To switch Verbose/Non-Verbose mode (Verbose mode is default), the following APIs are available:
+```
+DLT_VERBOSE_MODE();
+DLT_NONVERBOSE_MODE();
+```
+
+### Logging parameters
+The following parameter types can be used. Multiple parameters can be added to a single log message. The size of all logging parameters together should not exceed 1390 bytes, including the DLT message header.
+
+Type | Description
+--- | ---
+DLT_STRING(TEXT) | String
+DLT_CSTRING(TEXT) | Constant String (not send in non-verbose mode)
+DLT_UTF8 | Utf8-encoded string
+DLT_RAW(BUF,LENGTH) | Raw buffer
+DLT_INT(VAR) | Integer variable, dependent on platform
+DLT_INT8(VAR) |Integer 8 Bit variable
+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_UINT8(VAR) | Unsigned 8 Bit 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
+DLT_HEX8(UINT_VAR) | 8 Bit hex value
+DLT_HEX16(UINT_VAR) | 16 Bit hex value
+DLT_HEX32(UINT_VAR) | 32 Bit hex value
+DLT_HEX64(UINT_VAR) | 64 Bit hex value
+DLT_BIN8(UINT_VAR) | 8 Bit binary value
+DLT_BIN16(UINT_VAR | 16 Bit binary value
+DLT_PTR(PTR_VAR) | Architecture independent macro to print pointers
+
+###	DLT C++ Extension
+Important note: By default, C++ Extension is disabled in ADIT platform. It can be enabled by setting the CMake option: *WITH_DLT_CXX11_EXT=ON*.
+The DLT C++ extension was added to DLT in version 2.13 . This approach solves the need to specify the type of each argument for applications written in C++ by using C++ templates and function overloading. The following shows the usage of this API extension:
+
+```
+#define DLT_LOG_CXX(CONTEXT, LOGLEVEL, ...)
+#define DLT_LOG_FCN_CXX(CONTEXT, LOGLEVEL, ...)
+
+
+DLT_LOG_CXX(ctx, DLT_LOG_WARN, 1.0, 65);
+DLT_LOG_FCN_CXX(ctx, DLT_LOG_WARN, "Test String", 145, 3.141);
+```
+
+This works as well with C++ standard containers like std::vector, std::map, std::list. Of course, the logToDlt function can be overloaded to print user defined structures or classes.
+```
+struct MyStruct
+{
+    int64_t uuid;
+    int32_t interfaceId;
+    int32_t registrationState;
+};
+
+template<>
+inline int logToDlt(DltContextData & log, MyStruct const & value)
+{
+    int result = 0;
+
+    result += dlt_user_log_write_string(&log, "(");
+    result += logToDlt(log, value.uuid);
+    result += dlt_user_log_write_string(&log, ",");
+    result += logToDlt(log, value.interfaceId);
+    result += dlt_user_log_write_string(&log, ",");
+    result += logToDlt(log, value.registrationState);
+    result += dlt_user_log_write_string(&log, ")");
+
+    if (result != 0)
+    {
+        result = -1;
+    }
+
+    return result;
+}
+```
+
+###	Check if a specific Log Level is enabled
+In some scenarios it might be necessary to check if a specific Log Level is enabled or not, before log data is send to DLT Library. The macro is defined as follows:
+DLT_IS_LOG_LEVEL_ENABLED(CONTEXT,LOGLEVEL)
+In general, there is no need to check the active Log Level to decide if a log message can be send to not. This is handled inside the DLT_LOG macro.
+
+## DLT Injection Messages
+DLT provides an interface to register injection callbacks which can be sent by a DLT Client (e.g. DLT Viewer) to the application. An injection message callback is always registered for a specific context. The API to register a callback is defined as follows:
+
+```
+DLT_REGISTER_INJECTION_CALLBACK(CONTEXT, SERVICEID, CALLBACK);
+```
+
+Injection message Service IDs must be bigger than 0xFFF, because IDs up to 0xFFF are reserved for DLT Daemon control messages.  
+The callback function needs to have the following definition:
+```
+int injection_callback(uint32_t service_id, void *data, uint32_t length);
+```
+For example, registering a callback function for a specific context with the service ID 0x1000 might look like:
+```
+DLT_REGISTER_INJECTION_CALLBACK(mycontext, 0x1000, injection_callback);
+```
+From DLT Viewer, an injection message can be sent by right-clicking the corresponding context in the project view (“Send injection”). A dialog will pop up to specify the injection data as shown below.
+
+![alt text](images/dlt-viewer-send-injection-dialog.png "DLT Viewer Send Injection Callback")
+
+## Log level changed callback
+A callback function can be registered to be called whenever the Log Level of a context changed. The usage is similar to DLT_REGISTER_INJECTION_CALLBACK.
+```
+DLT_REGISTER_LOG_LEVEL_CHANGED_CALLBACK(CONTEXT, CALLBACK)
+```
\ No newline at end of file
diff --git a/doc/dlt_glossary.md b/doc/dlt_glossary.md
new file mode 100644
index 0000000..06f0cb9
--- /dev/null
+++ b/doc/dlt_glossary.md
@@ -0,0 +1,24 @@
+# Glossary
+
+Throughout the documentation specific terms are used. Those are defined below.
+
+Back to [README.md](../README.md)
+
+Term  | Definition
+----- | ----
+Application ID | Application Identifier is a unique identifier for an application registered at the DLT Daemon. It is defined as 8bit ASCII character. e.g. "APP1". Each Application can have several sub-components each having a unique context ID
+Context ID	| This is a user defined ID to group log and trace messages produced by an application. Each Application ID can own several Context IDs and the Context IDs shall be unique within an Application ID. The identification of the source of a log and trace message is done with a pair of Application ID and Context ID. It is composed by four 8 bit ASCII characters.
+Control Message	| A control message is send by a connected client application (e.g. Log Viewer) to the DLT Daemon that includes an action request. E.g. change the Log level of a certain application).
+DLT Daemon | The DLT Daemon is the central component which receives all logs and traces from the DLT user applications. The DLT Daemon forwards all logs and traces to a connected DLT client (e.g. Log Viewer) or stores them optionally in a file on the target.
+DLT Viewer | The DLT Viewer is the GENIVI Log Viewer implementation. It is a Qt-based desktop application able to run on Windows and Linux operating systems. Further information and source code can be found here: https://github.com/GENIVI/dlt-viewer
+Gateway DLT Daemon | In a Multi-Node system, the DLT Daemon running on the Node directly connected to a Log Viewer is called Gateway DLT Daemon (if configured as Gateway). It forwards log messages from Passive DLT Daemons to Log Viewers and command/control messages from Log Viewer(s) to Passive DLT Daemon(s).
+Injection Message | An injection message is a control message for a specific DLT application.
+Log Consumer | A log consumer is an application connected to the DLT Daemon (DLT Client) that receives log messages and stores (e.g. Logstorage) or displays them (e.g. Log Viewer). A log consumer can run on the same operating system or on a remote host pc.
+Log Level | A log level defines a classification for the severity grade of a log message.
+Log Viewer | A client application or tool used to view log information on a host pc. DLT-viewer is the supported Log Viewers.
+Multi-Node System | A system with more than one node.
+Node | A node represents an operating system, e.g. Linux, AUTOSAR or a container having its own DLT Daemon instance. Only one DLT Daemon should run on a node. In the context of DLT, Node and ECU describe the same thing.
+Node Identifier	| Unique Identifier of a node (node ID). In DLT, the node ID is defined by __EcuID__ set in _dlt.conf_ configuration file.
+Passive DLT Daemon | A passive DLT Daemon runs on a node without direct connection to a Log Viewer. All communication between a passive DLT Daemon and a Log Viewer has to be send via the Gateway DLT Daemon.
+Trace Status | The trace status provides information if a trace message should be send. Supported States are ON or OFF
+Verbose / Non-Verbose Mode | The DLT supports Verbose and Non-Verbose Mode. In _Verbose_ mode, all logging data including a type description is provided within the payload. Furthermore, Application ID and Context ID are transferred as part of the message header. In _Non-Verbose_ mode, description about the sender (Application ID, Context ID) as well as static strings and data description is not part of the payload. Instead, this information is stored in a file that needs to be parsed by a Log Viewer. The log message contains a unique message ID instead which allows a mapping between received log message and information stored in the file.
\ No newline at end of file
diff --git a/doc/dlt_multinode.md b/doc/dlt_multinode.md
new file mode 100644
index 0000000..1a970e7
--- /dev/null
+++ b/doc/dlt_multinode.md
@@ -0,0 +1,84 @@
+# DLT MultiNode
+
+Back to [README.md](../README.md)
+
+## Overview
+
+MultiNode allows to connect DLT Daemons running on different operating systems, e.g. in a virtualized environment.
+The central component is the Gateway DLT Daemon which connects external DLT Clients, like the DLT Viewer running on a host computer with Passive DLT Daemons running on nodes without a physical connection to external DLT clients.
+All communication between passive nodes and DLT Viewer has to be send via the Gateway node. The Gateway node forwards log messages coming from passive nodes to all connected DLT clients.
+The Gateway DLT Daemon also forwards command and control requests coming from DLT clients to the corresponding passive node.
+
+![alt text](images/dlt-multinode.png "DLT MultiNode")
+
+## Precondition
+
+The dlt.conf configuration file which is read by each DLT Daemon on start-up contains an entry to specify the ECU identifier (node identifier).
+It has to be ensured, that **each DLT Daemon in the System has a unique ECU** identifier specified.
+The ECU identifier is included in every DLT Message and is used to distinguish if a DLT message has to be forwarded to a passive node or handled by the Gateway DLT Daemon itself.
+
+## Configuration
+
+The dlt.conf configuration file provides an option to enable the Gateway functionality of a DLT Daemon.  
+The default setting is 0 (Off), which means the Gateway functionality is not available.
+
+```
+# Enable Gateway mode (Default: 0)
+GatewayMode = 1
+```
+
+### Gateway Configuration File
+
+The MultiNode configuration file has to be loaded by the Gateway DLT Daemon during startup.
+
+
+```
+[PassiveNode1]
+; IP Address. (Mandatory)
+IPaddress = 192.168.2.32
+; TCP port. Default 3490 is used if no port is specified
+Port = 3495
+; Passive node ECU identifier. (Mandatory)
+EcuID = ECU2
+; Connection to passive node only on demand. Default ‘OnStartup’ if not specified
+Connect = OnDemand
+; timeout in seconds
+Timeout = 10
+; Send following control messages after connection is established
+SendControl=0x03, 0x13
+; Send SerialHeader with control messages. Value in dlt.conf is used
+; as default if not specified
+SendSerialHeader=1
+```
+
+The configuration file is written in an INI file format and contains information about different connected passive nodes.
+Each passive node’s connection parameters are specified in a unique numbered separate section ([PassiveNode{1,2, …N}]).
+Because TCP is the only supported communication channel, the IPaddress and Port of the Passive 682 DLT Daemon has to be specified.
+
+With the Connect property it is possible to specify when the Gateway DLT Daemon shall connect to the passive node.
+The following values are allowed:
+    - OnStartup
+        The Gateway DLT Daemon tries to connect to the Passive DLT Daemon immediately after the Gateway DLT Daemon is started.
+    - OnDemand
+        The Gateway DLT Daemon tries to connect to the Passive DLT Daemon when it receives a connection request.
+
+The Timeout property specifies the time after which the Gateway DLT Daemon stops connecting attempts to a Passive DLT Daemon.
+If the connection is not established within the specified time, the Gateway DLT Daemon gives up connecting attempts and writes an error messages to its internal log.
+The following control messages are supported to be send to a passive node automatically after connection is established:
+    - 0x03: Get Log Info
+    - 0x13: Get Software Version
+
+## Using DLT MultiNode
+
+```
+Usage: dlt-passive-node-ctrl [options]
+Send a trigger to DLT daemon to (dis)connect a passive node or get current passive node status.
+
+Options:
+  -c         Connection status (1 - connect, 0 - disconnect)
+  -h         Usage
+  -n         passive Node identifier (e.g. ECU2)
+  -s         Show passive node(s) connection status
+  -t         Specify connection timeout (Default: 10s)
+  -v         Set verbose flag (Default:0)
+```
diff --git a/doc/dlt_offline_logstorage.md b/doc/dlt_offline_logstorage.md
new file mode 100644
index 0000000..d028862
--- /dev/null
+++ b/doc/dlt_offline_logstorage.md
@@ -0,0 +1,215 @@
+# DLT Offline Logstorage
+
+Back to [README.md](../README.md)
+
+## Introduction to DLT Offline Logstorage
+
+Logstorage is a mechanism to store DLT logs on the target system or an external device (e.g. USB stick) connected to the target.
+It can be seen as an improvement of the Offline Trace functionality which is already part of DLT.
+
+Logstorage provides the following features:
+- Store logs in sets of log files defined by configuration files
+- Log file content is configurable
+    - Configurable options are:
+        - Application identifier (single entry, list, wildcard)
+        - Context identifier (single entry, list, wildcard)
+        - Log level
+        - ECU identifier
+- Log files are configurable in terms of:
+    - File name and naming scheme
+    - File size
+    - Number of files
+- Log message synchronization strategy is configurable
+- Trigger start and stop logging using a control application
+- Integration into Udev device management
+
+
+## Configuration
+
+### General Configuration
+
+General configuration is done inside dlt.conf. The following configuration options exist:
+
+```
+##############################################################################
+# Offline logstorage                                                         #
+##############################################################################
+# Store DLT log messages, if not set offline logstorage is off (Default: off)
+# Maximum devices to be used as offline logstorage devices
+# OfflineLogstorageMaxDevices = 1
+
+# Path to store DLT offline log storage messages (Default: off)
+# OfflineLogstorageDirPath = /opt
+
+# File options
+# Appends timestamp in log file name, Disable by setting to 0 (Default: 1)
+# OfflineLogstorageTimestamp = 0
+
+# Appends delimiter in log file name, allowed punctutations only (Default: _)
+# OfflineLogstorageDelimiter = _
+
+# Wrap around value for log file count in file name (Default: UINT_MAX)
+# OfflineLogstorageMaxCounter = 999
+
+# Maximal used memory for Logstorage Cache in KB (Default: 30000 KB)
+# OfflineLogstorageCacheSize = 30000
+```
+
+### Configuration file format
+
+For DLT daemon to store logs the configuration file named “dlt_logstorage.conf” should be present in external storage or internal storage device (= given path in the file system).
+
+```
+[Filter<unique number>]              # filter configration name
+LogAppName=<APID>                    # Name of application to store logs from. Multiple applications can be separated by "," and ".*" denotes all applications
+ContextName=<CTID>                   # Name or names of contexts to store logs from. Multiple contexts can be separated by "," and ".*" denotes all contexts of the application
+LogLevel=<Log level>                 # Define log level, e.g. DLT_LOG_INFO or DLT_LOG_FATAL
+File=<file name>                     # Base name of the created files that containing the logs, e.g. "example". For further file naming scheme configurations see man dlt.conf
+FileSize=<file size in bytes>        # Maximum file size in bytes
+NOFiles=<number of files>            # Number of created files before oldest is deleted and a new one is created
+SyncBehavior=<strategy>              # Specify sync strategy. Default: Sync'ed after every message. See Logstorage Rinbuffer Implementation below.
+EcuID=<ECUid>                        # Specify ECU identifier
+SpecificSize=<spec size in bytes>    # Store logs in storage devices after specific size is reached.
+```
+
+The Parameter "SyncBehavior","EcuID" and "SpecificSize" are optional - all others are mandatory.
+
+An configuration file might look like:
+
+```
+[FILTER1]
+LogAppName=APP1
+ContextName=CON1,CON2
+LogLevel=DLT_LOG_INFO
+File=App
+FileSize=10000
+NOFiles=10
+
+[FILTER2]
+LogAppName=TEST
+ContextName=.*
+LogLevel=DLT_LOG_ERROR
+File=Test
+FileSize=250000
+NOFiles=5
+EcuID=ECU1
+SyncBehavior=ON_SPECIFIC_SIZE
+SpecificSize=5000
+
+[FILTER3]
+LogAppName=TEST
+ContextName=.*
+LogLevel=DLT_LOG_ERROR
+File=Test
+FileSize=250000
+NOFiles=5
+SyncBehavior=ON_FILE_SIZE,ON_DEMAND
+EcuID=ECU1
+```
+
+
+## Usage DLT Offline Logstorage
+
+Enable OfflineLogstorage by setting ```OfflineLogstorageMaxDevices = 1``` in dlt.conf.  
+Be aware that the performance of DLT may drop if multiple Logstorage devices are used; the performance depends on the write speed of the used device, too.
+
+Create the device folder:
+
+```
+mkdir -p /var/dltlogs
+```
+
+Create a configuration file and store it on into that folder or mount an external device containing a configuration file.
+
+Start the DLT Daemon. This is not necessary if the DLT Daemon was started already with Offline Logstorage enabled.
+
+Trigger DLT Daemon to use the new logstorage device:
+
+
+```dlt-logstorage-ctrl -c 1 -p /var/dltlogs```
+
+
+Afterwards, logs that match the filter configuration are stored onto the Logstorage device.
+
+
+```dlt-logstorage-ctrl -c 0 -p /var/dltlogs```
+
+
+The configured logstorage device is disconnected from the DLT Daemon.
+
+
+### Using dlt-logstorage-ctrl application
+
+```
+Usage: dlt-logstorage-ctrl [options]
+Send a trigger to DLT daemon to connect/disconnect a certain logstorage device
+
+Options:
+  -c         Connection type: connect = 1, disconnect = 0
+  -d[prop]   Run as daemon: prop = use proprietary handler
+             'prop' may be replaced by any meaningful word
+  -e         Set ECU ID (Default: ECU1)
+  -h         Usage
+  -p         Mount point path
+  -t         Specify connection timeout (Default: 10s)
+  -v         Set verbose flag (Default:0)
+```
+
+## Testing DLT Offline Logstorage
+
+The following procedure can be used to test Offline Logstorage:
+
+- Enable OfflineLogstorage by setting OfflineLogstorageMaxDevices = 1 in dlt.conf
+- Start dlt-daemon
+- The default search path of logstorage is: /tmp/dltlogs/dltlogsdevX
+  where X is a number in the range [1..OfflineLogstorageMaxDevices]
+
+- Create the device folder
+
+  ```$ mkdir -p /var/dltlog```
+
+- Create the configuration file "dlt_logstorage.conf" in this folder
+  and define filter configuration(s):
+
+  ```$printf "[FILTER1]
+  LogAppName=LOG
+  ContextName=TEST
+  LogLevel=DLT_LOG_WARN
+  File=example
+  FileSize=50000
+  NOFiles=5" > /tmp/dltlogs/dltlogsdev1/dlt_logstorage.conf```
+
+- Trigger dlt-daemon to use a new device
+
+  ```$ dlt-logstorage-ctrl -c 1 -p /var/dltlog```
+
+- Start dlt-example-user
+
+  ```$ dlt-example-user Hello123```
+
+- After execution, a log file is created in /var/dltlogs
+  e.g. example_001_20150512_133344.dlt
+
+- To check the content of the file open it with dlt-convert or DLT Viewer.
+
+## Logstorage Ring Buffer Implementation
+
+The DLT Logstorage is mainly used to store a configurable set of logs on an external mass storage device attached to the target.  
+In this scenario, writing each incoming log message directly onto the external storage device is appreciate, because the storage device might be un-mounted/suddenly removed at any time.  
+Writing each log message immediately avoids the problem of losing too many messages because the file system sync could not be finished before the device has been removed physically from the target.  
+On the other hand the DLT Logstorage feature might be used as well to store a configurable set of logs on any internal, nonvolatile memory (e.g. FLASH storage device).  
+Due to the reason of limited write cycles of a FLASH device the number of write cycles has to be reduced as much as possible.  
+But the drawback of losing log messages in case of an unexpected operating system crash has to be taking into account as well.  
+The obvious idea is to cache incoming log messages in memory and write the log data to disk based on a certain strategy.  
+Incoming log messages are stored in a data cache with a specific size. Depending on user defined strategy, the data cache is written onto the storage device、without relying on the sync mechanism of the file system.
+
+The following strategies are implemented:
+- ON_MSG - sync every message(Default)
+- ON_DAEMON_EXIT - sync on daemon exit
+- ON_DEMAND - sync on demand
+- ON_FILE_SIZE - sync on file size reached
+- ON_SPECIFIC_SIZE - sync after specific size is reached
+
+Note :
+1. Combinations (not allowed: combinations with ON_MSG,combination of ON_FILE_SIZE with ON_SPECIFIC_SIZE)
+2. If on_demand sync strategy alone is specified, it is advised to concatenate the log files in sequential order before viewing it on viewer.
diff --git a/doc/dlt_user_manual.txt b/doc/dlt_user_manual.txt
index c8f444e..54a252e 100644
--- a/doc/dlt_user_manual.txt
+++ b/doc/dlt_user_manual.txt
@@ -17,6 +17,8 @@ DLT User Manual
 ===============
 Alexander Wenzel <Alexander.AW.Wenzel@bmw.de>
 0.0.1, 2012/10/10: Initial version
+Christoph Lipka <clipka@de.adit-jv.com>
+0.0.2, 2018/12/13: updated version
 
 image::images/genivi_chrome_1_transparent.png[width=128]
 
@@ -138,15 +140,16 @@ See Manpage dlt-system(1).
 See Manpage dlt-system.conf(5).
 
 == DLT command line tools
-Four command line tools are provided together with DLT daemon implementation.
+six command line tools are provided together with DLT daemon implementation.
 
 These tools are:
 
 * Data logger: dlt-receive
 * Converter: dlt-convert
 * Sorter: dlt-sortbytimestamp
-* Configuration: dlt-control (planned)
-
+* Configuration: dlt-control
+* Logstorage: dlt-logstorage-ctrl
+* Multinode: dlt-passive-node-ctrl
 
 === dlt-receive
 
@@ -178,6 +181,22 @@ Ranges are essential when processing a DLT file covering more than a single rebo
 ==== Command line interface
 See Manpage dlt-sortbytimestamp(1).
 
+=== dlt-logstorage-ctrl
+
+==== Overview
+The dlt-logstorage-ctrl console utility is used to send a trigger to DLT Daemon to connect/disconnect/sync a certain offline logstorage device.
+
+==== Command line interface
+See Manpage dlt-logstorage-ctrl(1).
+
+=== dlt-passive-node-ctrl
+
+==== Overview
+The dlt-passive-node-ctrl console utility is used to send a trigger to DLT daemon to (dis)connect a passive node or get current passive node status.
+
+==== Command line interface
+See Manpage dlt-passive-node-ctrl(1).
+
 == DLT adaptors
 The DLT adaptors are used to interface legacy linux applications with the DLT daemon. Therefore, there are two adaptors:
 
@@ -248,7 +267,7 @@ DLT_REGISTER_CONTEXT(mycontext,"TEST","Test Context for Logging");
 ----
 
 .Important notes:
-* 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 fork() is called from an application after DLT_REGISTER_APP, dlt is reset in child process and user application needs to re-register application and contexts in child-process
 * 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.
 
 ==== Use one of the DLT macros or the DLT function interface:
diff --git a/doc/images/dlt-multinode.png b/doc/images/dlt-multinode.png
new file mode 100644
index 0000000..8ff0ddf
--- /dev/null
+++ b/doc/images/dlt-multinode.png
diff --git a/doc/images/dlt-viewer-send-injection-dialog.png b/doc/images/dlt-viewer-send-injection-dialog.png
new file mode 100644
index 0000000..bebea4b
--- /dev/null
+++ b/doc/images/dlt-viewer-send-injection-dialog.png