See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/377964975

Comprehensive Evaluation of Logging Frameworks for Future Vehicle

Diagnostics

Conference Paper · June 2023

DOI: 10.4271/2023-01-1223

CITATIONS READS

0 18

5 authors, including:

Sandra Bickelhaupt Michael Hahn

Universität Stuttgart Universität Stuttgart
4 PUBLICATIONS 4 CITATIONS 39 PUBLICATIONS 228 CITATIONS

SEE PROFILE SEE PROFILE

Andrey Morozov Michael Weyrich

Universität Stuttgart Universität Stuttgart
96 PUBLICATIONS 524 CITATIONS 387 PUBLICATIONS 4,003 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Andrey Morozov on 08 February 2024.

The user has requested enhancement of the downloaded file.

 Comprehensive Evaluation of Logging Frameworks for Future Vehicle
Diagnostics
Sandra Bickelhaupt, Michael Hahn and Nikolai Nuding – Mercedes Benz AG
Andrey Morozov, Michael Weyrich – University of Stuttgart
Abstract
More and more applications (apps) are entering vehicles.
Customers would like to have in-car apps in their
infotainment system, which they already use regularly on
their smartphones. Other apps with new functionalities also
inspire vehicle customers, but only as long as the customer
can utilize them. To ensure customer satisfaction, it is
important that these apps work and that failures are found
and corrected as quickly as possible. Therefore, in-car apps
also implicate requirements for future vehicle diagnostics.
This is because current vehicle diagnostic methods are not
designed for handling dynamic software failures of apps.
Consequently, new diagnostic methods are needed to support
the diagnosis of in-car apps. Log data are a central building
block in software systems for system health management or
troubleshooting. However, there are different types of log
data and log environment setups depending on the
underlying system or software platform. Depending on that,
the creation of log data takes place with different logging
approaches, leading to heterogeneous results that
complicates the analysis of log data. In order to classify
different types of log data, a taxonomy for log data is derived
systematically in this paper. This taxonomy is deduced from
identified challenges and heterogeneity regarding logging
and log data. Furthermore, the taxonomy is applied to
evaluate four logging frameworks for vehicle diagnostics
based on three software platforms that are commonly used
to operate in-car apps within vehicles: Android, AUTOSAR
Adaptive, and Java Standard Edition (SE). As these
platforms generate different types of log data, this leads to
determining and compare the differences between these
frameworks and their commonalities for deployment in
vehicles. In addition, the evaluation offers potential starting
points for future work regarding the utilization of log data
for future vehicle diagnostics and related methods.
Introduction
Vehicle attractiveness is increasingly determined by the
software in the vehicle and its functions [1]. Technical
features of a vehicle, such as driving performance, are no
longer the main deciding factor for some customer groups.
Personalization and customization of the vehicle are
increasingly decisive for customers. Thereby, applications
(apps) in the vehicle, known as in-car apps, can help to offer
flexible and valuable services for customers. In addition,
customers more and more desire to synchronize their
smartphone with the vehicle [2]. Until now, the infotainment
system in the vehicle is a control console, for example, for
the radio, the navigation system or for showing certain
vehicle data on the display. Currently, the infotainment
system can also be utilized as a control center for the use and
operation of apps. By integrating third-party apps such as
Spotify or Netflix into the infotainment system, customer
preference can be realized successfully [3]. Some vehicle
manufacturers are developing new in-house infotainment
systems to enable among other things this integration [4].
These systems run on automotive High Performance
Computers (HPCs) based on different operating systems.
Thereby different apps with their underlying software
frameworks can be executed on automotive HPCs [5]. In
comparison, other vehicle manufactures are using a special
version of Android, called Android Automotive, for vehicles
[4]. One of the main tasks of current vehicle diagnostics is
to detect and store failures of components or subsystems in
the form of Diagnostic Trouble Codes (DTCs) in ECUs and
to read them out of the ECUs so that repairs can be initiated
[6]. However, vehicle diagnostics is hardware-focused and
dynamic software failures are mostly not detected by current
methods. In order to ensure the functionality of apps, it is
important to diagnose dynamic software failures in addition
to static software failures, such as a communication
interruption to an app. For that reason, log data from apps
and their analyses can be helpful [7]. In the field of vehicle
diagnostics, a survey of experts indicates that these experts
also consider log data as a useful data source in the context
of vehicle diagnostics [8]. As the future vehicle diagnostics
is subject to the influences of the increasing integration of
software in the vehicle, log data can be a data source for
further analysis in order to be able to diagnose in-car apps in
vehicles.
The contribution of the paper is to evaluate four logging
frameworks for future vehicle diagnostics, based on the
Android, AUTOSAR Adaptive and Java platform used in
automotive HPCs, as well as their different kinds of log data.
Therefore, a taxonomy for log data is systematically
developed. On basis of this taxonomy, criteria are applied to
evaluate the logging frameworks. The evaluation results help
to identify what aspects can be considered when analyzing
log data for vehicle diagnostics in the future.
The rest of the paper is structured as follows. In Section
“Logging, log data and challenges”, issues about the
utilization of log data and challenges around logging and log
data are described. Section “Taxonomy for log data”
illustrates the developed taxonomy for log data. Afterwards,
in Section “Automotive High Performance Computer and
Software Frameworks”, the integration of automotive High
Performance Computers (HPCs) into vehicles and aspects
about in-car apps on automotive HPCs are presented. In
addition, the three logging frameworks Android, AUTOSAR
Adaptive and Java are described. In Section “Evaluation”,
the taxonomy is applied on these three frameworks for a Table 1. Overview of challenges around logging and log
comparison and results are discussed. Section “Summary data.
and Outlook” provides the conclusion and describes
directions for future work. Challenge Short description Related
work
Generation Software developers can set [9]
Logging, Log Data and Challenges print statements and logging
methods in the code to generate
different log events or log events
Landauer et al. [9] mention that various terminologies about can be generated by the system.
logging and log data are circulating through different
Quality Log quality can vary a lot, if [11]
publications. In this paper, the term logging frameworks multiple software developers
indicates that log files are generated out of software create logs in a project. This can
programs. The term log file points out that in such files log be related to, for example, the
data are stored. The terms log data and logs are used as logging aim, logging rules or
synonyms in this paper. Log data consist of a sequence of internationalization.
single- or multi-line events which are named with the term Inter- Adaption of logs to other natural [14]
log events. Event logs and log messages are synonyms for nationalization languages
log events. Inside these events there can be different Formats Log data can appear in different [11] [12]
parameters, as no unified log format exists. Terms such as formats. [15] [16]
fault, error, or failure are considered as synonyms in this Setup Log data can have different [16]
paper, basically describing a generic problem, even though setups.
there are differences between these terms in other papers, for Operation Different people use log data for [17]
example by Avizienis et al. [10]. The term failure is used various tasks and with different
within this paper hereafter. In the following sections, the interests.
utilization of log data and challenges around logging and log Analysis Big amount of logs, which make [11] [12]
data are discussed. manual log analysis almost not [18]
feasible. In addition, generation
of logs in fast rates, which
Utilization of Log Data makes efficient analysis
As described above, vehicle customers would like to use inevitable.
smartphone apps in their vehicles. In everyday life, for Appearance Log data contain intertwined [9] [12]
example, instant messaging apps are often used to dependencies and correlations
communicate immediately with other users or search which makes data preprocessing
engines provide answers to open questions [11]. However, difficult
such software systems are increasingly indispensable for Procedure Concserns where to log, what to [15] [19]
users and should be available at all time. In order to ensure log and how to log by inserting
log events in software systems.
their availability, the reliability of the underlying systems has
to be ensured. It is helpful to monitor the systems
continuously and to detect errors early on, before an app fails Generation
or major system downtimes occur. Often logs are the only One challenge, which influences the work with log data, is
data, which are available in relation to software runtime that some log events are created by print statements and
information. They are produced by logging statements, logging methods which are used by software developers [9].
which are placed by developers directly in the software Developers use these statements, for example, to understand
source code. Alternatively, the used logging framework program activities or to debug code. Besides the insertion of
produces some of them automatically. log events by developers, some of them can also be
generated directly by the underlying systems itself.
The majority of log events represent normal system
operations, for example starting or stopping of processes, Quality
virtual machines, or user accesses [9]. However, log events Another thing is that the logging statements are just as
are also produced when systems behave abnormal or when helpful as the information they provide. The quality of the
failures occur in the systems. These events are important for statements can vary a lot inside projects [11]. Related to that
forensic analysis or for system diagnostics to discover the challenge is the problem that software could be developed
roots of the problem or a bottleneck [12]. by different developers who use, for example, code sharing
platforms and do not know the original logging aim inside
Challenges Around Logging and Log the software project. Moreover, the software changes
Data continuously and new versions are released quickly. This
In the field of apps, logs can be useful to monitor the states makes manual updating of logging rules or how logging
of an app or for debugging [13]. Logs are helpful to statements are set in a project difficult for developers.
understand what an app is and was currently doing and the
sequence in which certain actions are executed. However, Internationalization
there are no clearly defined uniform guidelines for logging In addition, writing logs in different languages and their
software systems that apply to all systems [14]. For that internationalization is time-consuming and error-prone [14].
reason, nine major challenges around logging within related By adapting logs to other natural languages, developers can
work are identified. These challenges are summarized in define internationalized labels and create centralized files,
Table 1 and described in the following sections in more which store a list of predefined log event templates.
detail.
Formats
Additionally, a challenge is that log events can appear in
different formats, for example, due to the utilized logging
frameworks and programming languages [15]. Several
aspects or parameters have an influence on the log format.
In the following, five commonly used parameters are
introduced as an example: Identifiers, Log Levels,
Messages, Timestamps, and Unique Code Types.
A parameter that is used are identifiers. For example, with
process identifiers, messages or events can be related to tasks
or other events [11]. Depending on the log format, identifiers
may be specified differently.
Log levels are generally utilized to assign different severities
to individual log events. This can later be helpful to filter
among other things log data. By using different log levels as
parameter, this subdivision of the log data can be performed
and log information can be stored in different categories
[16]. An „error“ log level can be used, for example, to mark
log events which are added to the log data due to a failure in
the underlying system. Ideally, further information is
included in order to be able to analyze the error situation
precisely and that errors can be detected and corrected based
on respective log events. Log files can also be used to
generate statistics during normal operation of the
application. For this purpose, entries with a log level like
“info” can be utilized, for example, to get information about
successfully completed processes. Using the “debug” log
level, for example, more detailed information can be written
down to enable debugging [16]. It is helpful to activate this
log level only during debugging and preferably only for the
part of the system that is analyzed.
Another parameter are messages in textual forms [12]. These
messages are different depending on the information and
context they provide within a log event and look like normal
text. As the texts in the messages vary a lot, automated
analysis of these messages can be difficult for software
systems.
Often log events have timestamps as a parameter at the
beginning [12]. However, these time stamps can also be
challenging because sometimes they do not represent the
actual time of the generation of log events. This can be
caused, for example, by technological restrictions like delays
through buffering or time synchronization.
It is also possible to assign a unique code to each log event.
This can make it easier to trace where exactly the log event
came from [16].
Setup
The different setups in which log data can emerge is a further
challenge. Depending on which logging framework, system
or programming language is selected and used, log data have
different setups. Thereby it is possible that log data are stored
in a structured form, for example, with a list of comma-
separated values, or in a semi-structured form, for instance
with attribute-value pairs [16]. Alternatively, log data can be
unstructured, for example, with only free text of arbitrary
length or combinations thereof.
Operation
In addition, log data are used from different persons who
work on various tasks [17]. Tasks can be, for example,
forensic analysis or system diagnostic in finding root causes
or for rankings to analyze frequently used features of
customers. Flexible log data allows using it in various use
cases with different perspectives. However, as different
persons are working with log data, there can be conflicts
between their requirements toward the log data because of
for instance different interests and aims underlying to their
use cases.
Analysis
Beside to that, another challenge is that current software
systems become larger and larger with more complex
structures [11]. Thereby big amounts of logs are produced by
these systems, which makes manual log analysis almost not
feasible [18]. In addition, log data are also generated in fast
rates and efficient analysis methods are needed [12].
Appearance
Another challenge is that log data contain intertwined
dependencies as well as correlations between log events,
which make it non-trivial to preprocess these data for
analyses [9]. Additionally, log events can repeat over time,
for example, as parts of software programs are executed in
loops [12].
Procedure
Another challenge are the steps in the procedure and
questions that have to be clarified by inserting log events in
software systems. Chen and Jiang [19] named them “where-
to-log”, “what-to-log” and “how-to-log”. The challenge
“where-to-log”, is about determining the suitable logging
locations to collect findings about system runtime behavior.
“What-to-log” is used to highlight the challenge to provide
enough information in the logging events. Thereby it is to be
considered among other things, which parameters, for
example, identifier or message are relevant within the
protocol format and which information is helpful in each
individual parameter, for example, what is written inside a
message. The “how-to-log” challenge is about developing
and maintaining good value logging code. Gholamian and
Ward [15] added beside these three questions “whether-to-
log” as a fourth.
Taxonomy for Log Data
A taxonomy is a classification scheme for objects that helps
understanding and analyzing complex issues in a certain
domain [20]. It can provide a baseline for grouping objects
into a field by common characteristics.Nickerson, Varshney
et al. [20] analyze taxonomies of information systems. They
classify the approaches of the taxonomies into the following
three categories: (i) inductive, (ii) deductive, and (iii)
intuitive. The inductive approach involves looking at
examples or experiences that are then analyzed to determine
the dimensions and characteristics of the taxonomy. In the
deductive approach, a taxonomy is extracted from theory or
conceptualization. In this approach, the dimensions and
features in the taxonomy are identified through a logical
process based on a solid conceptual or theoretical grounding.
The intuitive approach is essentially spontaneous. The
researcher uses his/her understanding of the objects to be
classified to suggest a taxonomy based on the researcher's
perceptions.
In Figure 1, a generated taxonomy for log data is presented.
The taxonomy is derived with an inductive approach by
identifying the above discussed nine challenges within
Section “Challenges Around Logging and Log Data”
Figure 1. Taxonomy for log data based on the 5V of Big Data and the challenges for logging and log data.
The first level below the log data level in Figure 1 is based
on the 5Vs that are used in the definition of Big Data [21].
Value, Variety, Velocity, Veracity and Volume. As log data
are generated in large amounts in several software systems,
these data can be considered as Big Data [22].
This layer with the 5V represents meta characteristics which
are used as a basis for the selection of further criteria in the
taxonomy. Each broader criterion is a logical consequence of
a meta characteristic. In addition to the 5V meta
characteristics, there is also the classification object “Other”,
which has criteria that cannot be classified under the 5Vs.
On the second level in Figure 1 are the criteria, which can be
applied to classify log data objects. In addition to the criteria
derived from the challenges from Section “Challenges
Around Logging and Log Data", there are also the criteria
“Ownership” and “Data Occurrence”, which are derived
from Zrenner, Hassan et al. [23]. Additionally, there is a
criterion “Approach” which is deduced from the survey by
Chen and Jiang [24] with the examples conventional
approach, rule-based approach and distributed tracing.
Under the rule-based approach belongs, for example, the
aspect-oriented programming-based approach. In addition,
there are criteria “Origin”, “Output”, and “Benefit”. The
third, lowest level in Figure 1 comprises further criteria or
examples for the respective criteria. A branch with examples
is indicated by an aspect with three points leaving further
points open.
As seen in Figure 1, the taxonomy has three levels or
dimensions downwards from the term log data and most
often three examples on the third level. This means that this
taxonomy contains a limited number of dimensions and
features in each dimension as named as an important aspect
described by Nickerson, Varshney et al [29]. An extensive
classification scheme with multiple dimensions and features
would be difficult to understand and apply. The taxonomy
contains also enough dimensions and features to clearly
distinguish the objects of interest and allow for the inclusion
of additional dimensions and features [20].
regarding log data in the literature. These challenges can be
used for deploying criteria, which allows for the
classification of logging aspects.
Automotive High Performance
Computers and Logging
Frameworks
In general, writing log data are relatively simple and can be
done with various technologies [16]. For most programming
languages, there is a wide number of libraries that support
handling log files. These libraries can be used to include the
logging framework. Nevertheless, as seen in Figure 1,
classifying log data is not trivial since different criteria can
be applied.
To apply the taxonomy to an example, logging frameworks
of the three software platforms Android, AUTOSAR
Adaptive and Java and their resulting log data are described.
However, the three platforms are first placed in the context
of the vehicle and automotive HPCs. This is described in the
first Section “Integration of Automotive High Performance
Computers (HPCs) Into the Vehicle Architecture”.
Afterwards the logging frameworks are explained in more
detail in Section “Logging Frameworks” and are then
compared with each other using the criteria from the
taxonomy.
Integration of Automotive High
Performance Computers (HPCs) Into the
Vehicle Architecture
The current Electric/Electronic (E/E) architecture of vehicles
consists of more than 100 decentralized Electronic Control
Units (ECUs) [25]. Due to more and more software functions
in the vehicle, this architecture with ECUs is approaching its
limitations. For that purpose, the current trend in the
automotive area is towards systems on which functions are
centralized and less decentralized ECUs are used. The
architecture is initially divided into domains and in the
longer term further subdivided into zonal clusters. For these
systems, larger ECUs with more computing power and
subcomponents are used, compared to normal ECUs [26].
These larger ECUs are often called automotive High
Performance Computers (HPC).
A simplified automotive HPC architecture is presented in
Figure 2, following [27] and [28]. As seen in Figure 2, an
automotive HPC consists of several layers such as multi-core
processor system, hypervisors, operating systems, software
frameworks and applications. For example, Android,
AUTOSAR Adaptive and Java apps can be integrated into
an automotive HPC, like in Figure 2. On the left side in
Figure 2 is the AUTOSAR Adaptive app stack. In the middle
of Figure 2 is a stack where a Java app can be executed and
on the right is the Android app stack. From these applications
on automotive HPCs, log data can be generated by applying
logging frameworks, which perform logging.
Figure 2. Simplified automotive HPC architecture with three
kinds of apps.
The paper focuses on these types of apps, because of the fact
that Android apps represent a large market segment and can
be delivered to vehicle customers via their integration into
automotive HPCs as in-car apps. In addition, the focus is on
AUTOSAR Adaptive apps because the context of
automotive HPCs is the automotive area and AUTOSAR is
typically used within the vehicle. Java apps are included
because some in-car apps could also be written in Java. In
addition, Java is also used in vehicle diagnostics, for
example, in the Open Diagnostics Data Exchange (ODX)
field in vehicles [29]. The ODX format is specified in the
ISO 22901 standard [30]. It is an Extensible Markup
Language (XML)-based format for the description of ECU
diagnostic data [29]. This data exchange format can be used,
for example, to describe diagnostic services, flash data or
diagnostic jobs. An ODX diagnostic job contains a single
process that communicates with ECUs several times and is
implemented in the Java programming language. Besides,
Java is a programming language which is among the top 4
languages in the TIOBE index of October 2022 and is widely
used [31].
Logging Frameworks
In the following sections, the four logging frameworks based
on the three platforms Android, AUTOSAR Adaptive, and
Java are introduced, as a basis for their comparison. This
helps to understand how logging is performed under the
mentioned frameworks. Figure 3 gives an overview of the
introduced logging frameworks hereafter classified related
to the underlying platform. The three points in Figure 3
indicate respective examples of other logging frameworks
that are not covered in this paper. The term software
framework refers in this paper to the runtime environment of
a software platform, which allows running apps on operating
systems.
From the Android platform, the common logging framework
is used, which is based on the “android.util.Log” package.
The AUTOSAR Adaptive Log and Trace logging framework
is utilized by the AUTOSAR Adaptive platform. By the Java
platform, the two logging frameworks” log4j” in version 2
and “java.util.logging” are applied, as they are identified in
literature as commonly used frameworks.
Figure 3. Overview of the four logging frameworks
investigated in this paper.
Android Logging Framework
In the Android environment, an app developer inserts
activations for log events at selected points in the program
code, which can be called to generate messages at critical
points in the app's program code [13]. Furthermore, there are
also logs that are returned automatically by the Android
system. The logging system in Android is built-on a set of
structured circular buffers [32]. This means that when the
storage space in a ring buffer is used up, old data are
removed while new data are added. The available buffers are
fixed and defined by the system. Five relevant ring buffers
are: main, system, crash, event and radio, which represent
the five types of logs available in the Android environment.
The log events of the ring buffer main, system and crash are
output by default. The events of the radio and events ring
buffers have to be requested explicitly.
In the logging system of Android, all log events can be read
out with the Logcat command-line tool or the Logcat
window in the Android Studio environment [32, 33]. The
Logcat command-line has also the option to write log event
outputs to a file. The logs include events from the Android
system as well as log events that the developer has set up for
its own Android app. In addition, the stack trace can be read
out [34]. A stack trace is generated whenever an app crashes
because of an error or an exception and contains information
about the cause of an error or an exception. When using the
Logcat command-line tool or the Logcat window, the
Android Debug Bridge (ADB) is also required [32, 33].
However, the ADB is first used for control, since it is
responsible for communication between the development
system on a computer, like the Android SDK, and the
connected Android devices.
To generate own log data, for example, as an App developer,
the Android SDK offers an own log class within the util
package named "android.util.Log" [35]. This class contains
different methods to write various log events. The messages
can be viewed through the Logcat window in the Android
SDK or through the Command line tool. Generally, one of
six methods of the Log class is used [33]. These methods are
associated with a respective log level. In general, there are
the following six log levels, written in descending order of
importance: Assert, Error, Warning, Info, Debug, and
Verbose. Verbose logs are used during the development of
the app and are the default setting, while debug logs are
compiled in but removed at runtime. Error, warning and info
logs are kept each time.
Each of the log methods takes usually two parameters of type
String [36]. The first parameter is assigned to the tag of the
message, which informs about the origin of the message and
can be used to identify it later. The second parameter
contains the output text. This means the actual content of the
message. Sometimes there is a third parameter named
Throwable that can also be defined.
Basically, each log event with one or more lines of code
consists of different metadata fields beside the tag and the
log level [37]. Log level is sometimes named as priority. By
control the log output format, the format of a log event can
differ, depending on which metadata fields are displayed. In
default mode, also named as threadtime, the first data fields
are the date and the invocation time. Afterwards each log has
a log level and a tag. In addition, it has also a Process ID
(PID) and a thread Identifier (TID). PID and TID can be the
same if there is only one thread. At the end, the log events
have a text message. A list of other supported formats of the
Logcat command-line tool are presented in [37].
The above introduced logging framework is commonly used
in Android and also the one described in the Android
documentation [29, 33]. Other logging frameworks may also
work in the Android ecosystem. However, these are not
addressed within this paper.
AUTOSAR Adaptive Logging Framework
On the AUTOSAR (Automotive open system architecture)
Adaptive Platform, AUTOSAR Adaptive Logging offers an
interface for applications to send logging information to a
communication bus, console, or file system [38]. In order to
provide logging information within AUTOSAR in a
standardized transport and presentation format, a protocol is
required. This is why the AUTOSAR consortium has
standardized the Log and Trace (LT) protocol. In this paper,
the documentation for the specification of log and trace from
release 2021 [38] is used as well as the documentation for
the log and trace protocol specification from release 2020
[39].
The Diagnostics Log and Trace (DLT) protocol is a GENIVI
Log and Trace daemon implementation of the LT protocol,
which is used in the Adaptive Logging by the backend and
by the Logging client [38]. The AUTOSAR Adaptive user
applications can submit their logging information to the Log
and Trace backend via logging APIs, which are written in the
C++ programming language and integrated in a Software
System (SWS). The logging information can be applied by a
Logging client, which can filter or sort the received
information. Besides, the Communication Management API,
ara::com, can also address the Logging APIs. In the
AUTOSAR environment, log events are often named as log
messages.
In a system, such as an ECU or the entire vehicle, each
application process has a specific application ID and
description to differentiate the logs of the various
applications in the system [38]. To distinguish the logs from
various logical groups within an application process, each
context in the application process has a specific context ID
and description. The log mode indicates the destination
where the passed log information can be stored, like the
communication bus in a network, console or file system. If
the log mode is adjusted to a file, the log file path is required
to know the destination directory path. Log messages that
are logged before the logging framework can process them
are placed in a queue. The size of the queue is predefined. If
this size is exceeded, the oldest entries are deleted.
There are two types of classes for log messages [39]. Non-
modeled messages add all arguments of an event inside an
internal event buffer and serialize them for output. In the
DLT protocol, these messages are also called "verbose"
messages. These messages are mainly used during
development or if enough memory and high network
bandwidths are given. Modeled messages are designed to
reduce traffic on the network by omitting certain static parts
of a message from the network. These parts are instead added
to the ARXML model of the application. In the DLT
protocol, these messages are also known as "non-verbose"
messages. An application for displaying protocol messages
can display the complete messages by combining the static
parts of the model with the dynamic parts of the received
messages.
The log level, named by AUTOSAR Adaptive severity level,
provides meta information about the log level of a passed
logging information and can act like a filter [38]. This means
if a certain log level is addressed, only log events, which
have a higher or same log level, are processed while the
others are ignored. In general, there are the following six log
levels, written in descending order of importance: Fatal,
Error, Warning, Info, Debug, and Verbose.
The event or message format of the DLT protocol has a
Standard Header, an optional Extended Header and a
Payload segment [39]. The content of these three parts are
described hereafter. For further details inside each part, it is
referred to [39]. The Standard Header contains the following
three to six fields in the mentioned order:
• Header type, (Byte 0)
• Message Counter (Byte 1)
• Length (Byte 2-3)
• ECU ID, which is optional (Byte 4-7)
• Session ID, which is optional (Byte 8-11)
• Timestamp, which is optional (Byte 12-15)
The Extended Header consists of the following four fields:
• Message Info (Byte 0)
• Number of Arguments (Byte 1)
• Application ID (Byte 2-5)
• Context ID (Byte 6-9)
The Payload segment differs depending if the verbose mode
or the non-verbose mode is used for log events [39]. The
payload of messages, which are sent in verbose mode for
non-modelled messages, contains also a complete
description of the parameters besides the parameter values
themselves. This means that on the one hand, no external file
is required for additional logging information. However, on
the other hand, a higher volume of data is transmitted on the
bus. Verbose mode can be applied on ECUs that have enough
memory and a high network bandwidth. Due to the self-
description, the stored data on the external client can be
interpreted at any time and without further external
information. In the payload, the individual arguments are
composed of a Type Info field followed by a Data Payload
field. Non-Verbose Mode for modelled messages can be
used with the payload to transmit parameter values without
the need for meta-information about them or additional
properties to the parameters. A special message ID is
attached to the payload that refers to a separate, external file
or an ARXML system description in which the description
of the payload layout is given. After the Message ID, non-
static Data is provided, for example, with parameters.
Java Logging Frameworks
Within Java, there is a built-in logging framework in the
java.util.logging package [40]. However, there are also
several other external frameworks that can be used in Java.
Chen and Jiang [14] conduct an empirical study to
investigate the usage of various Java logging frameworks, as
some software systems such as Android applications, web
services or Big Data platforms are implemented in Java and
logging is widely used there. Chen and Jiang name logging
frameworks within the study as Logging Utilities (LU). In
the top ten most popular LUs, according to Chen and Jiang's
research, there are the following six LUs for logging
purposes in software systems of desktop applications or
server-based systems:
• Apache Commons Logging
• Java.util.logging
• LogBack
• Log4j 1.x, version 1.x
• Log4j 2, version 2
• SLF4J
SLF4J is the most popular LU due to its improved
performance and compatibility with other LUs [14]. SLF4J
and Apache Commons Logging are logging APIs, but they
delegate the writing of logs by logging frameworks such as
Log4j or Java.util.logging [41].
Log4j 2 is the enhancement of Log4j 1.x. The logging
framework Log4j has six methods to generate logs with
corresponding log levels [42]. In general, there are the
following six log levels, written in descending order of
importance: Fatal, Error, Warn, Info, Debug, and Verbose. In
Log4j, an appender is used to format a log event into a
desired layout [43]. There are different layouts possible, for
example, CSV, HTML, JSON, RFC5424, or XML with
various meta fields inside each layout. The logging
framework logBack also offers different formats [44].
The package java.util.logging.Logger, from the Java logging
framework java.util.logging, procures various classes and
interfaces as logging utilities for the programming language
Java [45]. With the included logging APIs, logs can be
written [46]. The Logger object is the main entity so that
applications can execute logging calls. These Logger objects
assign LogRecord objects, which are used to pass logging
calls between the logging framework and individual log
Handlers. The Handlers export LogRecord objects to various
destinations, such as memory. Both Loggers and Handlers
can use logging levels and (optionally) filters to decide
whether they are interested in a particular LogRecord. A
Formatter can be used to locate and format a message before
it is published to some other location. Some Handlers can
pass outputs to other Handlers.
Within the Logger class there are different methods to
produce log events [47]. These methods are associated with
different standard logging levels defined in the Level class.
The levels can be used to control the logging output, since
activating a certain level also activates logging on all higher
levels. In general, there are the following seven log levels,
written in descending order of importance: Severe, Warning,
Info, Config, Fine, Finer and, Finest. Furthermore, it is
generally possible for third parties to define additional
logging levels through subclasses of levels.
In total, there are two standard Formatter [46]
implementations in this logging framework. The
SimpleFormatter can be used to write short human-readable
summaries of log entries. Thereby the following seven
arguments are possible [48]:
1. Format: in which the format string or the default format
is specified
2. Date: Represents the date and time of the log event
3. Source: The string representing the caller or the name
of the logger
4. Logger: Name of the loggers
5. Level: Log level
6. Message: Formatted log message
7. Thrown: String representing the throwable associated
with the log entry and its traceback
The first argument can be used to customize the format,
allowing it to change depending on the individual Java
project. The second formatter is the XML-Formatter, which
can be used to write detailed and standardized XML-
structured logs [46]. However, with a subclass, formatting in
XML can be overridden and the message field can be
reformatted. In addition, additional formatters can be
developed.
In general, it can be seen from the mentioned Java logging
frameworks, like log4j, LogBack and java.util.logging, that
there are similar methods for the generation of logs.
However, the format of the logs can be chosen very flexibly,
because it is possible to use different layouts with various
parameters.
Evaluation
After presenting the logging frameworks, selected criteria of
the taxonomy about log data are used to evaluate four
logging frameworks of the three software platform
frameworks: Android, AUTOSAR Adaptive and Java. For
Java, the two well-known frameworks java.util.logging and
log4j 2 are evaluated in the following. The selected criteria
are key characteristics to distinguish the logging
frameworks. Table 2 shows the evaluation in form of a
comparison. The aspect Further Characteristics in Table 2
provides additional information, which is not covered by the
other criteria. Later, the results presented in Table 2 are
discussed in more detail.
Table 2. Evaluation of the four logging frameworks: Android.uitl.Log, AUTOSAR Adaptive Log and Trace, java.uil.logging and
log4j 2.

Logging Frameworks
Android Platform AUTOSAR Adaptive Platform Java Platform
Android.util.Log AUTOSAR Adaptive Log and java.util.logging log4j 2
Trace
Format Identifier Process-ID (PID) ECU ID, Session ID, Application Depends on the established format
Thread-ID (TID), ID, Context ID, or all
or both

Log Assert, Error, Fatal, Error, Warning, Info, Severe, Warning, Info, Fatal, Error, Warn, Info,
level Warning, Info, Debug, Verbose Config, Fine, Finer, Debug, Trace
Debug, Verbose Finest
Tag Yes Over the Application ID and/or For example, over the With a Parameter
Context ID Source with the
SimpleFormatter
Text Yes Yes (non-modeled or modeled Yes
messages)
Time- Yes Yes Yes
stamps
Other Default format: standardized Log and Trace (LT) Formatter can be used, Appender can be used to
Criteria / Classification aspects

format threadtime protocol (→Diagnostics Log and like SimpleFormatter format logs in a desired
aspects Trace (DLT) protocol) or XMLFormatter, or layout, e.g. CSV,
individual formats can HTML, XML or
be created individual formats can
be created
Appearance Correlations, Dependencies, Repetition, or further
Generation Developers, Software system side, or further
Operation (major) Failure analysis Developed for vehicle Different areas
diagnostics
Origin Apps in-car Apps in-car Apps, Cloud Systems, or On Premise
Systems
Ownership Public Private Public
Setup Semi-structured Semi-structured Depends on format
Storage Console: Logcat Console, File, or Communication Console, File, or Cloud
Command-line or Bus System
Logcat window, or
File
Further • Circular ring • internal event buffer or • Define additional log levels through
Characteristics buffer queue subclasses of levels
• Stack trace • Log level equates to • Programming languages (natively): Java
• Programming Severity level
languages • API programming
(natively): (natively): C++
Java, Kotlin

Format Furthermore, it can be seen that logs from Android and

From Table 2 follows that the two Java frameworks,
java.util.logging and log4j 2, have several similarities across
the individual criteria. In the aspect of format, their default
options differ. With java.util.logging two formatters can be
used to define the log data format or individual formats can
be set up. With log4j 2, the definition of the format goes over
the desired layout and its integrated format components, or
an own format can be provided. Also, the log levels and how
tags are defined are different. AUTOSAR Adaptive specifies
the format of the log data with its standardized LT protocol.
However, it leaves some freedom in the configuration, since
some inner format components can be optionally used.
Android specifies a default format that is initially used if no
adjustments are applied by the developer. Besides the default
format, there are a few other formats where less content is
visible.
AUTOSAR Adaptive have predefined components in the
formats. Logs in Java, on the other hand, are very flexible in
their generation or format. For that reason, it might be useful
to focus on logs from AUTOSAR Adaptive and Android.
This is because in the direction of Java logs it is easier to
give indications of how logs there need to look in order to be
able to evaluate those using methods from automotive HPC
diagnostics for future vehicle diagnostics.
In addition, the number and meaning of the log levels in
Android and AUTOSAR Adaptive are comparable. Both
have six log levels and only the top log level has a different
naming. The log levels of log4j in Java would also be
comparable to Android and AUTOSAR Adaptive, but in
java.util.logging, for example, there are a different number
of log levels with different meanings. This makes it difficult
at first to include Java logs in further considerations of
AUTOSAR Adaptive and Android logs. As a result, there is
no uniform log level description in the Java framework,
which initially complicates the inclusion of Java logs in
further considerations of AUTOSAR Adaptive and Android
logs.
This means, that there are differences among the three
considered frameworks, Android, AUTOSAR Adaptive and
Java, in the respective log data formats. The logs, which are
generated in vehicles with the already established
AUTOSAR Adaptive framework have different format
components than the logs of Android apps. If Android and
AUTOSAR Adaptive logs are now evaluated together with a
method, the question arises how the log formats are handled.
Appearance and Generation
Within the log data, as shown in Table 2, there are
correlations, dependencies and repetitions among others
regarding the three logging frameworks. In addition, the log
data for the three frameworks are set up by developers or by
the software system side.
If log data are generated by developers and by the software
system side, it needs to be further explored whether the
generated log data are sufficient to perform efficient analyses
and whether failures in the vehicle can be found out of them.
Operation (major) and Origin
The log data in Android are primarily used for failure
analysis as seen in Table 2. AUTOSAR Adaptive log data are
utilized for vehicle diagnostics but currently only in manual
analysis by developers. Log data from the Java environment
can be applied in various areas. Android and AUTOSAR
Adaptive log data are typically found in apps, whereas Java
log data can occur not only in apps, they can also occur in
cloud systems or on premise systems.
Ownership
AUTOSAR Adaptive log data are owned by the respective
automotive company and is not publicly available, since it
refers, for example, to vehicle functionalities that may be
relevant for competition as presented in Table 2. Log data
from Android and Java are mostly freely accessible, since
both frameworks are publicly usable for developers.
Since AUTOSAR Adaptive log data are only accessible
within automotive companies, automotive HPC diagnostics
and the resulting future vehicle diagnostics are initially
determined by the internal steps in vehicles. In order to
inform external customers outside the vehicle about the
failures and diagnostic results, it is necessary to consider
how the results from the log data are communicated and
transported to them.
Setup
Android and AUTOSAR Adaptive log data consist of a semi-
structured setup based on their components in the format if
the defined formats are applied in the frameworks as seen in
Table 2. They are made up of structured, predefined text
fields and dynamic, free text fields. Log data in Java can
have a different structure depending on the format.
Storage
In Table 2, it is shown that all three frameworks can store log
data in files or provide them via the console. For Android,
the console is the Logcat window or the Logcat command-
line. AUTOSAR Adaptive log data can also be written to the
communication bus and transported further in the vehicle. In
the case of Java log data, the data can also be stored directly
in the cloud.
Further Characteristics
In the Android framework, there is the concept of circular
ring buffers to keep the log data temporarily. The stack trace
is used in Android whenever an app crashes due to an error
or exception and contains information about the causes of
the error or exception. It is helpful to use the verbose log
level only during app development and debug logs are
removed at app runtime. Typically, Android apps are
programmed with the Java or Kotlin programming
languages.
The AUTOSAR Adaptive framework supports internal event
buffers or queues for caching the logs. The log levels are
known as severity levels in AUTOSAR Adaptive. The
programming language of the logging API for AUTOSAR
Adaptive is C++. In Java frameworks, additional log levels
can be created by creating subclasses of levels. The
programming language for Java apps is traditionally Java.
Conclusion and Outlook
The aspects summarized in Table 2 and the taxonomy
presented in Figure 1 show that data logging is a complex
topic. There are different challenges to handle like, for
example, the varied parameters in the format or the storage
of the log data. In addition, no uniform logging approach
exists. This makes it difficult to perform further analyses
with the log data and to generate statements from log data.
In this paper, challenges of log data are identified and hereon
a taxonomy for log data is derived. Some benefits of
applying the taxonomy are, for example, to get a better
understanding of certain log data by classifying them or to
help by drawing conclusions from specific log data. In
addition, it also helps to compare and evaluate various types
of log data and select the most suitable one for a particular
application.
As an example, this taxonomy is applied in this paper to four
logging frameworks commonly used within the three
software platforms Android, AUTOSAR Adaptive and Java.
This makes it possible to evaluate the four frameworks, with
criteria based on the taxonomy, and to identify similarities
and differences.
In comparison of Android and AUTOSAR, for example, the
default log data formats have some similar standard
parameters like identifiers, log levels, tag, text, and time
stamps. Even the number of log levels is the same. In turn,
log data from Java logging frameworks has a variety, as
different log data formats can be established for specific
cases. The log level number can vary, depending on the
chosen Java logging frameworks.
A similarity of log data in Android, AUTOSAR Adaptive and
Java is, for example, that they have all characteristics of
correlations, dependencies, or repetition. These make log
data diagnostics quite challenging as these characteristics are
sometimes not easy identified. Furthermore, the concepts of
log data in Android and AUTOSAR are developed for a
specific environment. For Android, it is major the
application area for mobile devices and there apps. For
AUTOSAR it is the automotive area and apps on AUTOSAR
ECUs. Whereas, logs of the Java platform are used within
various areas and systems.
During the development of the taxonomy and there usage as
part of the evaluation, some topics for future work in the
field of automotive HPC diagnostic have emerged. The
following are a few examples.
A first future work direction could be to identify methods,
which can analyze log data efficiently in the vehicle
ecosystem. This would be significant, for example, to keep
in-car apps functional and to be able to detect failures in in-
car apps, especially software failures, at an early stage. In
this context, it makes sense to consider how a suitable,
uniform log format might be structured. This could be
advantageous because working with different log data
formats, such as from Android, AUTOSAR and Java, for
example, can complicate the analysis of log data if the
methods cannot rely on a uniform format. It could be useful
to focus first on data from Android and AUTOSAR Adaptive
apps, as these two can form the main app environment in the
vehicle. Afterwards, the findings can be applied to other
apps, such as ones built with Java.
Since logging technology has its origins in the IT domain, a
second future work direction could be to evaluate further its
suitability for the automotive ecosystem. For that reason, in
the future, the taxonomy as well as the results from Table 2
and other criteria could be used to assess the usage of logging
technology in the automotive environment and the vehicle in
particular.
References
1. X. Boucherat, “Power in your pocket: what's the future
of the car smartphone apps?,” Automotive World
Magazine, April 2021, no. 16, pp. 44–47, 2021.
2. U. Winkelhake, “Challenges in the Digital
Transformation of the Automotive Industry,” ATZ
Worldwide, 7-8, no. 121, pp. 36–42, 2019.
3. M. Pese, K. Shin, J. Bruner, and A. Chu, “Security
Analysis of Android Automotive,” in SAE Technical
Paper Series, 2020.
4. B. Eriksson, J. Groth, and A. Sabelfeld, “On the Road
with Third-party Apps: Security Analysis of an In-
vehicle App Platform,” in Proceedings of the 5th
International Conference on Vehicle Technology and
Intelligent Transport Systems, Heraklion, Crete,
Greece, 2019, pp. 64–75.
5. M. Steffelbauer, “SOVD - The Diagnostic Standard of
Tomorrow,” ATZ Electron Worldw, vol. 16, no. 4, pp.
44–48, 2021, doi: 10.1007/s38314-021-0591-1.
6. P. Subke, M. Moshref, and J. Erber, “In-Vehicle
Diagnostic System for Prognostics and OTA Updates of
Automated/Autonomous Vehicles,” SAE Int. J. Adv. &
Curr. Prac. in Mobility, vol. 2, no. 5, pp. 2963–2968,
2020, doi: 10.4271/2020-01-1373.
7. M. Davidekova and M. Gregu Ml, “Software
Application Logging: Aspects to Consider by
Implementing Knowledge Management,” in 2016 2nd
International Conference on Open and Big Data (OBD),
Vienna, 2016, pp. 102–107.
8. S. Bickelhaupt et al., “Challenges and Opportunities of
Future Vehicle Diagnostics in Software-Defined
Vehicles,” SAE Technical Paper, 2023-01-0847, 2023.
9. M. Landauer, S. Onder, F. Skopik, and M.
Wurzenberger, “Deep Learning for Anomaly Detection
in Log Data: A Survey,” Jul. 2022. [Online]. Available:
https://arxiv.org/pdf/2207.03820
10. A. Avizienis, J.-C. Laprie, B. Randell, and C.
Landwehr, “Basic Concepts and Taxonomy of
Dependable and Secure Computing,” IEEE
Trans.Dependable and Secure Comput., vol. 1, no. 1,
pp. 11–33, 2004, doi: 10.1109/TDSC.2004.2.
11. S. He et al., “A Survey on Automated Log Analysis for
Reliability Engineering,” ACM Comput. Surv., vol. 54,
no. 6, pp. 1–37, 2021, doi: 10.1145/3460345.
12. M. Landauer, F. Skopik, M. Wurzenberger, and A.
Rauber, “System log clustering approaches for cyber
security applications: A survey,” Computers & Security,
vol. 92, p. 101739, 2020, doi:
10.1016/j.cose.2020.101739.
13. J. Staudemeyer, Android mit Kotlin: Kurz & gut, 1st ed.
[Deutschland], Heidelberg: O'Reilly; dpunkt.verlag,
2018.
14. B. Chen and Z. M. Jiang, “Studying the use of Java
logging utilities in the wild,” in Proceedings of the
ACM/IEEE 42nd International Conference on Software
Engineering, Seoul South Korea, 2020, pp. 397–408.
15. S. Gholamian and P. A. S. Ward, “A Comprehensive
Survey of Logging in Software: From Logging
Statements Automation to Log Mining and Analysis,”
ArXiv, abs/2110.12489, 2021.
16. E. Wolff, Continuous Delivery: Der pragmatische
Einstieg, 2nd ed. Heidelberg: dpunkt.verlag, 2016.
17. T. Barik, R. DeLine, S. Drucker, and D. Fisher, “The
bones of the system,” in Proceedings of the 38th
International Conference on Software Engineering
Companion, Austin Texas, 2016, pp. 92–101.
18. Q. Wang, X. Zhang, X. Wang, and Z. Cao, “Log
Sequence Anomaly Detection Method Based on
Contrastive Adversarial Training and Dual Feature
Extraction,” Entropy, vol. 24, no. 1, p. 69, 2021, doi:
10.3390/e24010069.
19. B. Chen and Z. M. Jiang, “Characterizing and Detecting
Anti-Patterns in the Logging Code,” in 2017
IEEE/ACM 39th International Conference on Software
Engineering (ICSE), Buenos Aires, 2017, pp. 71–81.
20. R. Nickerson, U. Varshney, and J. Muntermann, “A
method for taxonomy development and its application
in information systems,” European Journal of
Information Systems, vol. 22, pp. 336–359, 2013.
21. R. K. Lomotey and R. Deters, “Towards Knowledge
Discovery in Big Data,” in 2014 IEEE 8th International
Symposium on Service Oriented System Engineering,
Oxford, United Kingdom, 2014, pp. 181–191.
22. Graylog, How Big Data and Log Management work
hand in hand. https://www.graylog.org/post/how-big-
data-and-log-management-work-hand-in-hand/
(accessed: Oct. 28 2022).
23. J. Zrenner, A. P. Hassan, B. Otto, and J. C. Marx
Gómez, “Data source taxonomy for supply network
structure visibility,” 2017.
24. B. Chen and Z. M. Jiang, “A Survey of Software Log
Instrumentation,” ACM Comput. Surv., vol. 54, no. 4,
pp. 1–34, 2022, doi: 10.1145/3448976.
 25. V. Bandur, G. Selim, V. Pantelic, and M. Lawford, 42. Apache Software Foundation, Custom Log Levels.
“Making the Case for Centralized Automotive E/E https://logging.apache.org/log4j/2.x/manual/customlog
Architectures,” IEEE Trans. Veh. Technol., vol. 70, no. levels.html (accessed: Nov. 3 2022).
2, pp. 1230–1245, 2021, doi: 43. Apache Software Foundation, Layouts.
10.1109/TVT.2021.3054934. https://logging.apache.org/log4j/2.x/manual/layouts.ht
26. Sebastian Ohl, “Simplifying Automotive High- ml (accessed: Nov. 3 2022).
Performance Computer Development by Using a Pre- 44. C. Gülcü et al., Chapter 6: Layouts.
integrated Software Platform,” in GMM-Fachbericht, https://logback.qos.ch/manual/layouts.html (accessed:
vol. 99, Automotive meets Electronics: Beiträge des 12. Nov. 3 2022).
GMM-Symposium, March, 10 – 11, 2021, Online- 45. Oracle Docs, Package java.util.logging.
Veranstaltung, 1st ed., Berlin: VDE VERLAG, 2021, https://docs.oracle.com/javase/7/docs/api/java/util/log
pp. 34–38. ging/package-summary.html (accessed: Oct. 26 2022).
27. Continental AG, Body High-Performance Computer: 46. Oracle Docs, Java™ Logging Overview.
More Intelligence with Server-based E/E Architectures. https://docs.oracle.com/javase/7/docs/technotes/guides
https://www.continental-automotive.com/en- /logging/overview.html (accessed: Oct. 26 2022).
gl/Passenger-Cars/Architecture-and- 47. Oracle Docs, Class Level.
Networking/Body-High-Performance-Computer https://docs.oracle.com/javase/8/docs/api/java/util/log
(accessed: May 24 2022). ging/Level.html (accessed: Oct. 26 2022).
28. Dr. Boris Böhlen, Dr. Oliver Meyer, Dr. Simon Becker, 48. Oracle Docs, Class SimpleFormatter.
Dr. Roland Stoffel, Mario Alberto Ortegón-Cabrera, https://docs.oracle.com/javase/7/docs/api/java/util/log
“Diagnose von HPCs über SOVD,” in Diagnose in ging/SimpleFormatter.html (accessed: Oct. 26 2022).
mechatronischen Fahrzeugsystemen XV: Predictive
Maintenance, Remote Diagnose, KI / Maschinelles
Lernen, Standardisierung, HU und ePTI, Dresden,
Contact Information
2022, pp. 113–128.
29. M. Steffelbauer and B. Rösch, “ODX simplifies Sandra Bickelhaupt, M. Sc.
diagnostic process chain,” AutoTechnol, vol. 6, no. 2,
e-mail: sandra.bickelhaupt@mercedes-benz.com
pp. 56–59, 2006, doi: 10.1007/BF03246947.
30. ISO 22901-1:2008: Road vehicles - Open diagnostic
data exchange (ODX) - Part 1: Data model Acknowledgments
specification, International Organization for
Standardization (ISO). This publication is based on the research project SofDCar
https://www.iso.org/standard/41207.html (19S21002), which is funded by the German Federal
31. TIOBE, TIOBE Index for October 2022. Ministry for Economic Affairs and Climate Action.
https://www.tiobe.com/tiobe-index/ (accessed: Oct. 28
2022).
32. Android Developers, Logcat command-line tool.
https://developer.android.com/studio/command-
line/logcat (accessed: Oct. 12 2022).
33. Android Developers, Write and View Logs with Logcat.
https://developer.android.com/studio/debug/am-logcat
(accessed: Oct. 11 2022).
34. Android Developers, Analyze a stack trace.
https://developer.android.com/studio/debug/stacktrace
s (accessed: Oct. 24 2022).
35. A.-R. Mawlood-Yunis, Android for Java Programmers,
1st ed. Cham: Springer International Publishing;
Imprint: Springer, 2022.
36. Android Developers, Log.
https://developer.android.com/reference/android/util/L
og (accessed: Oct. 24 2022).
37. Android Developers, Logcat command-line tool.
https://developer.android.com/studio/command-
line/logcat#Overview (accessed: Oct. 11 2022).
38. AUTOSAR, “Specification of Log and Trace: Adaptive
Platform,” no. 853, 2021.
39. AUTOSAR, “Log and Trace Protocol Specification:
Foundation,” no. 787, 2020.
40. B. Baesens, A. Backiel, and S. Vanden Broucke,
Beginning Java programming: The object-oriented
approach. Indianapolis, Ind.: Wrox/Wiley, 2015.
41. U. Post, Besser coden, 1st ed. Bonn: Rheinwerk Verlag,
2018.

View publication stats