Embed Size (px)
Citation preview
FAKULTÄT FÜR INFORMATIK
DER TECHNISCHEN UNIVERSITÄT MÜNCHEN
Master’s Thesis in Automotive Software Engineering
Context Modeling for Dynamic Configuration of
Automotive Functions
Florian Grigoleit
FAKULTÄT FÜR INFORMATIK
DER TECHNISCHEN UNIVERSITÄT MÜNCHEN
Master’s Thesis in Automotive Software Engineering
Kontextmodellierung als Grundlage für dynamische
Konfigurierung von Fahrzeugfunktionen
Context Modeling for Dynamic Configuration of Automotive
Functions
Bearbeiter: Florian Grigoleit, M.Sc.
Aufgabensteller: Apl. Prof. Peter Struss
Betreuer: Apl. Prof. Peter Struss
Abgabedatum: 17. September 2012
ii
I assure that I single handedly composed this master’s thesis, only supported by declared
resources.
Ich versichere, dass ich diese Master’s Thesis selbstständig verfasst und nur die
angegebenen Quellen und Hilfsmittel verwendet habe.
___________________ __________________________________ Florian Grigoleit Place, Date
iii
In Kooperation mit
Eine Veröffentlichung der vorliegenden Arbeit oder von Teilen daraus ist nur mit Genehmigung
der Fraunhofer-Einrichtung für Systeme der Kommunikationstechnik ESK gestattet.
Full or partial publication of this Thesis is only permitted with approval of the Fraunhofer-
Institute for Communication Systems ESK
Autor: Florian Grigoleit, M.Sc.
Professor: Apl. Prof. Dr. Peter Struss
Betreuer: Dipl.-Inform. Gereon Weiß (Fraunhofer ESK)
Abgabedatum: 17. September 2012
iv
Acknowledgements
An dieser Stelle möchte ich mich bei Herrn Professor Struss und Herrn Weiß bedanken,
die mich während meiner Master’s Thesis umfangreich unterstützt haben.
v
Zusammenfassung
Kontextmodellierung, insbesondere für Fahrzeuge, ist ein Forschungsgebiet mit einer
Vielzahl von Anwendungen. Eine solche Anwendung ist die Anpassung der
Systemkonfiguration an den aktuellen Kontext. Das Ziel dieser Arbeit ist, die dynamische
Bestimmung der jeweils aktiven Funktionen eines Fahrzeugs in Abhängigkeit des
Fahrzeugkontexts zu unterstützen. Dazu wird ein Modell zur Erkennung und Darstellung
von Fahrzeugkontexten konzipiert. Mit Hilfe dieses Modells ist es möglich, die dem
Fahrzeug zur Verfügung stehenden Umgebungsinformationen zu einer
Situationsbeschreibung zu aggregieren und darzustellen. Die resultierende Darstellung
basiert auf der Unterteilung des Kontexts in Teilaspekte. Diese wurden anhand der
vorhandenen Umgebungsinformationen und der von ihnen abhängigen
Fahrzeugfunktionen definiert. Mittels der Situationsbeschreibung lässt sich die
Konfiguration der jeweils aktiven Fahrzeugfunktionen so anpassen, dass stets die zur
Erkennung der jeweiligen Fahrzeugsituation notwendigen Funktionen bereit stehen, aber
gleichzeitig der Energieverbrauch reduziert werden kann. Das Konzept wurde
prototypisch implementiert und in einer Simulationsumgebung an einer beispielhaften
Fahrzeugkonfiguration getestet. Dabei wurde eine Reduzierung der durchschnittlich
aktiven Funktionen um 24% gegenüber einer konventionellen Steuerung der Funktionen
erreicht, bzw. eine Reduzierung um 12% gegenüber einer simpleren, nur auf der Position
des Fahrzeugs beruhenden Steuerung der Funktionen.
vi
Abstract
Context modeling, especially for automotive applications, is a research area with a
large variety of applications. One application it the self-adaptation of the system’s
configuration based on contextual knowledge. The objective of this study is to dynamically
assist the ascertainment of every active automotive function depending on the car’s
context. To this end, a model is introduced for recognizing and representing contextual
information for automobiles. By applying this model it becomes feasible to provide cars
with an abstract situation description based on detailed knowledge about the car’s state.
The situation description divides the contextual information into several aspects, based on
existing environmental information as well as on car systems influenced by these aspects.
Using the information provided by the context model, the car system can adapt its
configuration accordingly. Context model and context recognition have been designed to
assist determining the set of functions required to recognize and manage the active
situation, as well as reducing the average energy consumption of E/E functionality in cars.
A prototype of the concept was implemented and simulated using an exemplary car
system. In simulation, a reduction of the average active car functions of 24% compared to
a conservative system was achieved. Comparing the reduction against a system with a
simple activity control based on location, a reduction of 12% was achieved.
vii
Table of Contents
Acknowledgements ............................................................................................................................................. iv
Zusammenfassung ................................................................................................................................................. v
Abstract .................................................................................................................................................................... vi
List of Tables .......................................................................................................................................................... ix
List of Figures .......................................................................................................................................................... x
List of Algorithms ................................................................................................................................................ xi
1. Introduction .................................................................................................................................................. 1
1.1 Motivation and Overview ............................................................................................................ 2
1.2 Objectives ............................................................................................................................................ 4
1.3 Thesis Organization ........................................................................................................................ 5
2. Problem Analysis and Requirements .................................................................................................. 6
2.1 Problem Analysis ............................................................................................................................... 6
2.2 System Requirements .................................................................................................................... 10
3. Related Work on Context Modeling, Qualitative Reasoning, and Smart Cars .................. 12
3.1 Defining Context and Context Awareness ............................................................................. 12
3.2 An Introduction to Context Modeling ..................................................................................... 14
3.3 Uncertainty in Context Modeling .............................................................................................. 16
3.4 Methods of Qualitative Reasoning ............................................................................................ 17
3.5 Context Awareness in Smart Cars ............................................................................................ 18
4. Design of a Context Model for Self-Adapting Automotive Systems ...................................... 20
4.1 Considerations on Context Modeling in Automotive Environments.......................... 20
4.2 Defining and Analyzing Context - Based Self-Adaptation ............................................... 23
4.3 Specifying Context Information and Context Attributes ................................................. 26
4.3.1 Selecting and Classifying Context Influences ............................................................. 28
4.3.2 Abstracting Context Information .................................................................................... 33
4.3.3 Analyzing and Specifying Context Situations ............................................................. 37
viii
4.4 Designing Context Model and Context Manager ................................................................. 38
4.4.1 Defining Communication between the Context Manager and Configuration
Manager 38
4.4.2 Defining Structure and Behavior of the Context Manager .................................... 39
4.4.3 Enhancing the Model to Verify Context and to Provide Fault Tolerance ........ 44
4.4.4 Ensuring and Evaluating Modifiability and Genericity .......................................... 49
4.5 Discussion ........................................................................................................................................... 54
5. Design Evaluation and Simulations of an Exemplary Car System......................................... 56
5.1 Considerations on Model Evaluation and Simulation ...................................................... 56
5.2 Design of an Exemplary Automotive System and its Architecture ............................. 57
5.3 Simulations and Performance Evaluation ............................................................................. 59
5.4 Discussion and Concept Evaluation ......................................................................................... 61
6. Concluding Remarks and Future Work ............................................................................................ 64
Bibliography .......................................................................................................................................................... 65
Appendix A ............................................................................................................................................................ 67
Glossary .............................................................................................................................................................. 67
List of Abbreviations..................................................................................................................................... 68
Appendix B ............................................................................................................................................................ 70
Exemplary Car Functions............................................................................................................................ 70
Context Attributes ......................................................................................................................................... 73
Appendix C ............................................................................................................................................................. 75
Simulation Results ......................................................................................................................................... 75
ix
List of Tables
Table 1: Effect on Context Influences on Car Functions ..................................................................... 21
Table 2: Possible Variations of the ACC ..................................................................................................... 23
Table 3: Data Sources and Car Functions employed in the Example Car .................................... 26
Table 4: Classifying Exemplary Context Influences based on Impact ........................................... 29
Table 5: Update Rate of selected Context Information ....................................................................... 31
Table 6: Influences with frequency and preconditions....................................................................... 31
Table 7: Variables selected for the example Context Model ............................................................. 32
Table 8: Significant Intervals for Velocity ................................................................................................. 35
Table 9: Context Attributes and Attribute Values of the Example Car ......................................... 36
Table 10: Modified Values for Driving Conditions ................................................................................ 53
Table 11: Status of Requirements ................................................................................................................ 54
Table 12: Reduction of Function Activity in Percent Depending on Self-Adaptation Type . 61
Table 13: Function Activity [%] depending on the Preferred Velocity ........................................ 75
Table 14: Function Activity [%] depending on the Likelihood of Rain on Function Activity
.................................................................................................................................................................................... 75
Table 15: Function Activity [%] depending on the Likelihood of Congestions on Function
Activity .................................................................................................................................................................... 75
Table 16: Function Activity [%] depending on the Likelihood of Accidents and
Construction Sites ............................................................................................................................................... 76
Table 17: Function Activity [%] depending on the Percentage of Night Drives ....................... 76
x
List of Figures
Figure 1: 3-Layered Architecture for Data Abstraction ........................................................................ 7
Figure 2: Exemplary Context Influences ................................................................................................... 21
Figure 3: Exemplary System Reaction to Changing Context ............................................................. 22
Figure 4: Relationship Context and Car System ..................................................................................... 24
Figure 5: System Boundaries between Context and Car System .................................................... 25
Figure 6: 3-Layered Architecture and Abstraction Layers ................................................................ 27
Figure 7: Integration the Process of Data Abstraction in the 3-Layered Architecture .......... 28
Figure 8: Abstracting relevant Information ............................................................................................. 30
Figure 9: Data Abstraction for the Context Model ................................................................................ 33
Figure 10: Creating Context Attributes based on Location-Specific Context Information ... 34
Figure 11: Sequence Diagram Context Forwarding ............................................................................. 39
Figure 12: Concept map of the Context Manager .................................................................................. 40
Figure 13: Structure Context Manager....................................................................................................... 41
Figure 14: Class Diagram for Context Recognition ............................................................................... 42
Figure 15: Temporal Data Management .................................................................................................... 42
Figure 16: Applying the Behavior Concept to the System Architecture ...................................... 43
Figure 17: Context Verification Process .................................................................................................... 46
Figure 18: Procedure to Analyze Impact of Different Car Functions ............................................ 52
Figure 19: ClassDiagramm ContextManager ........................................................................................... 58
Figure 20: Function Activity based on the driving style ..................................................................... 59
Figure 21: Functions activity dependent on likelihood of rain ........................................................ 60
Figure 22: Function Activity depending on Self-Adaptation Mode ................................................ 61
xi
List of Algorithms
Algorithm 1: Procedure to Determine Context Information relevant for our Application .. 37
Algorithm 2: Data Mapping Process ............................................................................................................ 44
Algorithm 3: Selecting Contradictory Context Information .............................................................. 48
Algorithm 4: Procedure to Include New Car Functions or Data Sources ..................................... 51
1
1. Introduction
Software has become arguably the most important innovation factor for cars. Every new car
generation uses significantly more software functions than the one before, as described in [1].
While three decades ago, software was mostly used for engine controls or similar low-level
functions, it nowadays affects every aspect of car development and functionality. One of the
results was the immense increase in electronic devices and, thus, the rapidly growing system
complexity. Currently, the reduction of system complexity along with the number of busses and
Electronic Control Units (ECUs) is one of the most important challenges in automotive software
engineering. Reducing the number of ECUs and breaking away from the long-standing principle
“one function – one ECU” naturally leads to a variety of new problems. One of the most
challenging issues is that now different software functions compete with regard to shared
resources. This issue is even more urgent in case of failing or malfunctioning ECUs.
Furthermore, since electric and electronic devices become more and more numerous and
important in current cars, it is essential to establish ways to increase their energy-efficiency.
Apart from more obvious approaches like power-efficient devices, it is crucial to explore more
advanced methods, for example, techniques to reduce the average number of active devices in a
car at runtime.
One promising solution is self-adapting software. This kind of software is able to adapt
itself to current needs. So, in case of a failing ECU, the software could simply redistribute the
functions of the failed ECU to other ones. By further exploring this approach, we achieve a
distributed system capable of enabling or disabling various subsystems or software functions as
needed. This method also allows to reduce the number of active subsystems for energy saving
and to reduce the required computational efforts. This appears to be an auspicious application,
as energy consumption in cars, especially in electric cars, is one of the major challenges in
modern automotive research. Range limitation, environmental guidelines, cost efficiency are
only a few automotive aspects affected by energy consumption.
Considering the following context situation: A car drives fast on an interstate with little
traffic and clear weather at midday. This situation requires the activation of several assistant
systems, like the Adaptive Cruise Control (ACC) or the Lane Departure Warning (LDW). Other
functions, like a Night Vision System (NVS), or the Junction Assistant System (JAS) are not
required in this specific situation. When the situation changes, for example, because the car
leaves the interstate, the context manager would adapt the functions accordingly. Obviously,
such a system has to be able to recognize the current context situation precisely, in order to
determine the according configuration.
2
This study results in a design scheme for context modeling in automotive applications.
The proposed approach yields a modifiable, platform independent context model. In
combination with a system for self-adaptation of car functions, the presented solution
offers the possibility to reduce computational efforts and energy consumption. The
achievable reduction is largely dependent on the employed car functions and their
characteristics. The model evaluated in this study is designed generically and can easily be
adapted for different car systems and moderately different goals.
To analyze and evaluate the characteristics of the resulting model a prototypical
implementation was created. The goal of the simulations has been to determine the
feasibility and the extent of reducing function activity in car systems with context
awareness. To simulate the model an exemplary automotive system, consisting of data
sources and car functions, was used as a test environment. This car system was also used
as a case study to illustrate problems and results in this thesis. The simulated car
architecture was based on approaches for self-adapting distributed software system, as
described in [2]. The simulations yielded to a 24% reduction of system activity.
Considering the required effort and overhead of such a system we conclude that context
awareness is suitable for the mentioned purposes. However, actual reductions of
computational efforts and energy consumption will vary depending on the employed
platform.
1.1 Motivation and Overview
In this thesis, we exploit the possibility of reducing energy consumption by adapting a
set of car functions to its context. By applying this approach, the system basically switches
off functionality unnecessary or unadvisable in specific situations. Naturally, this cannot
be applied to the entire range of E/E devices in a car, since a vast number of systems are
more or less permanently required while other functions have a significant influence on
the car’s safety. Hence, we have to limit efforts on non-vital functions and subsystems.
To be able to adapt the system to its context requires providing a sound model of the
current situation and all contextual information necessary for the adaptation. The
objective of this study has been to design a context model for self-adapting automotive
software and determine whether and to what extent it is feasible to reduce energy
consumption in cars.
Context modeling is a wide field of research with a large scope of applications. The
focus of context modeling in automotive applications often lies in describing either
3
location or state and behavior. This narrow definition of context is criticized in [3], where
A. Schmidt et. al. propose a larger definition of context and it’s context. The precise
definition of context largely depends on how and where context is used, as mentioned in
[4]. For our task, context can be described as a set of variables that influence the usability
of car functions or, considering the limitations mentioned above, advanced driver assistant
systems. Variables in the automotive context will be called Context Variables. Context
Variables that influence the car’s configuration are called Context Influences. Other
expressions used within the scope of this study are defined in the Glossary in Appendix A.
The resulting context model basically consists of an aggregation of abstract, high-level
contextual information, called Context Attributes. A context attribute, such as Scenario,
describes a certain aspect of the car’s context. The state of Scenario for example, describes
the current location, like Interstate, of the car. Attributes describe all knowledge about the
car’s surrounding and state relevant for determining which car functions can or should be
used in a specific situation. Attributes are obtained by analyzing and interpreting a set of
low-level data sources. Low Level Data are generally gained by sensors, external data
sources or user input. Usually low level data have to be analyzed to obtain the desired
information. Such hardware-independent information is called Context Information, e.g.
the velocity of the vehicle. Context attributes and context information are chosen based on
their influence on car functions. Therefore, certain context variables have to be omitted
since they do not significantly influence functionality. To gain a higher level of abstraction
and to reduce complexity, we use methods of qualitative reasoning to map quantitative
context information into qualitative attribute values.
As we have to expect incorrect, incomplete or imprecise data, we have to ensure the
thorough verification of data. This is even more important, because incorrectly identified
context situations not only increase energy consumption, but may affect the driver’s
attention and comfort, and presumably endanger car and passengers. Faulty data is
usually found during all steps of data handling, thus verification is required on all
abstraction levels. Since this study does not deal with specific sensors or subsystems we
only work on verification methods for higher, platform-independent levels. Data
verification is achieved by observing plausibility, tendencies and likelihoods. For example,
if the Driving Condition Attribute is in Fast state and the Scenario Attribute in Interstate we
conclude that the situation is plausible, while on the other hand Fast and Parking would be
regarded as implausible.
4
Albeit, this study does not treat the self-adapting software and its characteristics, we
have to consider configuration as it defines the context model. The basic assumption
regarding the configuration manager is that it will handle the problem of providing the
correct configuration as a constrain satisfaction problem, in which car functions require
certain context conditions and distinct context situations allow a variety of car functions
but also require certain functions to be identified. For example the ACC should only be
used on motorways or interstates, thus, it requires functions that can identify the car’s
location. Furthermore, we have to consider that configurations are expected to be robust,
meaning that it is neither efficient nor safe to frequently switch between situations.
Energy, safety, and comfort concerns require that system configuration changes are
minimized. Thus, we want the context situation to be as robust as possible. Configuration
changes shall only occur if the situation has definitely changed and the tendency supports
the likelihood of the new situation. On this basis, we defined the boarders of the
qualitative values rather vague so that the value of the context attributes stays in its
previous state until it is positively in the next state.
1.2 Objectives
This study focuses on modeling automotive context on a coarse-grain scale, well suited
to allow a safe and stable configuration of car systems. The major aim of this study was to
create a context model consisting of attributes based on characteristics and limitations of
today’s car functions. Using this model the car system shall be able to adapt itself in a way
that yields in an energy efficient configuration and distribution of car functions. The
fundamental issue for this system is that it has to work under the guideline that as long as
there is no indication that a car function should not be used it can be used. Following this
guideline the extent of the possible reduction in energy consumption is clearly limited.
Therefore, a major objective of this study is to explore whether it is possible and practical
to save energy by context awareness. Furthermore, resulting from this guideline we can
entail the minor goal of creating a robust context model that allows an efficient and stable
self-adaptation of the car subsystems.
One of the most important non-functional requirements for the context model is
modifiability and genericity. The context model as well as the entire context management
system, has to be designed in a sufficiently generic way to allow a variety of modifications.
Future implementations will use different data sources and control different car functions
than those we used as bases for this study. Therefore, differences depending on the
manufacturer and the installed equipment have to be dealt with. The solution has to
5
provide developers with efficient methods to modify the context model according to the
car equipment. Furthermore, the model will probably be used for use cases other than
reducing energy consumption. Thus, modification methods must comprise ways to handle
these use cases. All in all, the context model will be designed with focus on platform- and
manufacturer independence.
In addition, it should not interfere with safety critical functions. Furthermore, the
system has to be able to work under real-time conditions in an embedded environment.
Further requirements will be presented in section 2.2.
1.3 Thesis Organization
This thesis has been organized as follows: Chapter two presents an outline of the issues
addressed by this work. Its second section summarizes requirements for the final solution.
Chapter three summarizes research on context modeling, smart cars, and adaptive software.
We present an introduction to the principles of qualitative modeling and reasoning.
Furthermore, basic knowledge of methods used during this study is offered.
The actual work on context modeling in automotive application is presented in chapter four.
Here, we discuss the implication of the requirements given in chapter two and include them into
the design approach. Later on, a modifiable architecture for a context recognition system will be
presented, followed by schemes to recognize and describe context. Moreover, the handling of
faulty data and context information will be addressed. The chapter concludes by analyzing the
obtained context model and design procedures.
In chapter five we explore feasibility and efficiency of the proposed model by simulating a
prototypical implementation of an exemplary car system. To support the reliability of the
simulations, design aspects of adaptive car system architectures will be discussed. The car
system has been realized using a framework, developed for simulating embedded software
solutions, by the Fraunhofer ESK. This framework has also been used for conducting the
simulations. The following section consists of an evaluation of system architecture and
simulation results.
Chapter six will conclude the thesis. Here, the obtained model and simulation results will be
analytically discussed. Thus, the feasibility of the design from chapter four will be evaluated on
the simulation results from chapter five. The last section summarizes the results of this study
and offers a view on future work.
6
2. Problem Analysis and Requirements
Chapter two offers a detailed description of purpose and priorities of the presented
study. A brief introduction into the occurring issues and challenges will be followed by a
description of requirements and specifics of the desired system. Problem and
requirements will be explained with an exemplary reference car, to be introduced in this
chapter. Throughout the thesis this exemplary car will serve as a straightforward way to
describe problems, issues, and design details.
2.1 Problem Analysis
The problem addressed by this work can be illustrated on an exemplary car. The car is
equipped with a variety of advanced driver assistant systems, presented in Appendix B. All
these systems consist of sensors, or other data sources, ECUs, and actuators. Their
functionality and activity mainly relies on user input and on obtained data. For example
the ACC is only available for a certain speed range, but certain aspects of its behavior rely
on user input. In a conventionally equipped car, these functions are either always active,
or can only be activated by user input. But, in a self-adaptive system, like in [2] and
described in [5], the functions will be dynamically activatable by the system. Such a system
requires two key components: First, the system needs to aggregate the gathered data to
receive a more abstract representation of its state and environment. Second, it has to use
this representation to configure the car functions accordingly. This study focuses on the
problem set, in particular how to represent relevant information about the context for the
configuration manager.
The main objective of this study has been the design of a reliable context model.
Consequently, determining a sound definition of context will be the first step. This
objective has been addressed from two different perspectives. Firstly, we will look into
context modeling and representation from a generic point of view. By doing so, we receive
a broader vision on context and how to describe it. Afterwards, we focus on context from
the car configuration systems perspective. We can thereby acquire knowledge about
necessary context influences and important aspects about the connection of context and
self-adaptation.
As an initial step, context is analyzed in a general way, independently from domain
characteristics. Detailed under 3.1 and 4.1, we choose to define context as an infinite set of
context variables, each with a vast set of values. The variables cannot be influenced by the
7
context aware system in any significant way. This definition also includes the driver. Even
though, it is likely that the driver will change driving behavior according to context
influences. For example, if the system informs the driver about an accident ahead, it is
possible that he will change his route to avoid a resulting traffic congestion. The reason for
including the driver into the context is that his behavior has impact on configuration and
cannot directly be influenced or predicted by the context manager.
Context variables can be roughly classified as observable and unobservable ones. Or, in
a more practical way, into observed and unobserved ones. Since we do not want to
increase the number of sensors or data sources in a car we have to content ourselves with
the variables observed by existing sensors.
However, this set of variables is still too extensive to be useful, since we also observe
variables without sufficient importance for the configuration system, like irrelevant
objects identified by the camera system e.g. trees or parking cars. As the temporal
behavior of different variables varies from static, in case of maps, to frequently changing in
case of driving maneuvers, we have to find further classification methods. Additionally, we
have to establish a procedure to choose variables with relevance for specific car
functionality. This objective and its implications will be further discussed in chapter 4.2
and 4.3.
Another crucial issue is extracting platform-independent information from acquired
data. The majority of existing data sources provides hardware-specific low level data.
Thus, we will use more abstract data, prepared by signal processing or similar techniques
to describe the context situation. Introducing an abstraction level between raw data and
context representation, as shown in Figure 1, ensures a certain degree of hardware- and
configuration independence. A similar architecture for data abstraction was proposed by
[4].
Context Model
Platform-Independent Data
Sensor Data
Figure 1: 3-Layered Architecture for Data Abstraction
8
During the next phase, the emphasis is on evaluating context from a configuration
point of view. The required model has to provide a self-adaptive system with relevant
information for readapting the systems configuration. I.e. after determining what
information is required for specific car functions, it has to be ensured that the context
model includes this specific type of information. For example, the ACC requires
information about the car’s location, thus location has to be included in the context model.
Analyzing the relevant contextual information and affected car functions, we have to
address problems like optimizing the context update frequency, the handling of incorrect
and incomplete contexts and a range of similar issues. Two other problems driven by
configuration are establishing the most efficient way to inform the configuration manager
about context situations and situation changes and to find an appropriate representation
of the context.
The insight into system adaptation also provides us with requirements needed for
designing the context model, for example the optimized coarseness of the model. That is
the degree of granularity of the context model. I.e. we have to determine which influences
are going to be included in the model, and how finely their values will be grained. E.g.
considering the weather attribute. Here we could either simply distinguish between clear
or rain, or in an extremely extensive case between light rain, strong rain, light snow etc.
Analyzing possible system configurations leads to the major aim of this study: Saving
Energy. As briefly mentioned in chapter 1.1, the precise definition of context always
depends on the aim of the context model. As the primary goal here is to reduce energy
consumption and computational efforts of E/E – systems in automotive applications, we
have to design the context model accordingly.
Regarding the context problem from the two angles, available data and required
information, we observed that data sources as well as car functions are largely platform-
dependent, while the information layer mentioned above will be relatively independent
from the platform-specific characteristics. Thus, we concluded that a three layered
architecture represents the most promising approach, as it allows us to encapsulate the
context model from minor hardware changes. I.e. a different sensor for already measured
contextual information will not lead to changes in the context representation. The design
of the model and the system architecture will be further discussed in sections 4.3 and 4.4.
After creating the context model, we have to deal with incorrect, incomplete or
imprecise data. In a real car, we have to cope with a large number of potential errors,
including sensor imprecision, malfunctioning devices, or quantization errors in signal or
9
image processing. Faulty data exist in every technical system. Errors occur in every stage
of context recognition, thus every layer needs its own error-handling. Since incorrect
context information may trigger incorrect configuration decisions and is therefore, either
counterproductive or even dangerous, it has to be handled thoroughly. For example, if the
system identifies the location incorrectly, due to the precision of GPS data it is possible
that the system will be activated that are unsuitable for the correct position, like activating
the JAS on an interstate.
To address the problem of energy consumption we have to clarify several issues. The most
prominent is to determine if context - based self-adaptation is suitable for reducing energy
consumption. Lacking an adequately equipped car, it is necessary to simulate the context
modeling approach on an exemplary system. This raises the question of what an
exemplary system should look like. Also, a number of design decisions for the simulations,
like the simulated architecture, have to be addressed. Furthermore, as we do not design
the self-adaptation manager itself, we have to come up with a sufficiently similar approach
to configure the car functionality. As bases for the exemplary car system, we use the
example car mentioned afore.
Furthermore, as noted in chapter 2.2, one of the primary requirements for the final
solution is modifiability. Thus, approach and solution have to focus on energy
consumption but should offer means to adapt structure and design to different variants of
vehicles equipped with different functions, configurations, and goals.
All in all, the following tasks are required for solving the above mentioned problems:
Determining car functions suitable for self-adaptation and analyzing how they
are affected by context conditions
Describing significant influences on car functions and determining how finely
grained they have to be represented
Determining a relevant set of attributes and their distinctive values
Creating a simple, efficient and modifiable architecture for the context
manager
Defining an appropriate representation for the context model
Creating a process for adapting the context manager to an individual variant
and to extent it to new functions
Outlining a method for handling incorrect, incomplete or imprecise context
information
Designing a realistic car system for simulating and evaluating the context model
10
Simulating context recognition and car function activity
Due to the limited scope of this study, several important aspects will not be treated or
will be dealt by using simplifying assumptions. In particular, context prediction and self-
adaptatation will be omitted from this work.
2.2 System Requirements
This chapter presents the requirement elicitation for the desired context management
system (CMS). First, the functional requirements will be discussed in descending order
from self-adaptation to data acquisition. Second, non-functional requirements and
development guidelines will be elucidated.
R1 – The energy consumption of the car system should be reducing
R2 – To achieve R1, the car’s context has to be recognized and represented to
provide the self-adaptive system with sufficient information to adapt the
configuration
R3 – To ensure fault-tolerance and error detection corresponding methods have to
be created
R4 – To allow an efficient implementation of the context manager processes and
guidelines to execute modifications and to guarantee platform- independence of
the context model have to be designed
R5 – The system has to be developed for efficiency and safety to allow a
deployment under safety-critical real-time conditions
R1 - The most significant functionality of the system is reducing the energy
consumption of the handled car functions. This requirement has to be considered for all
occurring issues and design decisions. To achieve a reduction satisfying the efforts and
overhead, it is necessary being able to activate or deactivate car functions.
R2 - The context manager has to provide the self-adaptive system with information
about the car’s context. The supplied information has to be sufficiently detailed to allow
the system to take a clear decision on which functions to enable or disable. Therefore, the
provided context representation has to be unambiguous.
R3 - Expecting a certain level of faulty data, the context recognition has to be fault-
tolerant. This means that the system shall be able to cope with contradictory data due to
the accuracy of measurements, data that fall into range borders and failing sensors. Thus,
incorrect data have to be recognized and treated accordingly. In addition, contradictory
data have to be resolved by decisions based on evidence and safety, i.e., if the decision can
11
affect the car’s safety the system shall give priority to safety, and if the decision is
uncritical, the result should depend on which information is supported by a higher
evidence factor.
R4 - An important non-functional requirement in our case is modularity and
modifiability. Even though the required system is supposed to be platform-independent,
the larger part of the context model depends on the car’s assistant system and its data
sources. As mentioned earlier, attributes and context information have to be determined
by analyzing their influence on the car functions and by their observability. Hence, it is not
feasible to design a context model without any assumptions on the used car configuration.
However, regarding current and near future car systems, we can select a number of widely
used assistant systems with more or less similar characteristics. Moreover, modifiability is
not restricted to different platforms and car functionality, but also includes moderately
different use cases. Naturally, it is not reasonable to prepare a concept for all conceivable
demands. On the other hand, the concept should provide future developers at least with an
acceptable level of modularity and changeability as well as with a sound process to
execute such changes. The changes to be addressed include omission or addition of
assistant system and certain data sources.
R5 - Context model and context manager will be deployed in an embedded software
system with hard real-time restrictions. Therefore, it is imperative to design concept and
implementation as simple and efficient as possible and to follow guidelines for real-time
development. Concerning functional safety and safety of the automobile in general, it has
to be assured that highly critical functions shall not be affected by the CMS in any way.
Functions that are safety critical to an acceptable degree can be controlled by self-
adaptation.
12
3. Related Work on Context Modeling, Qualitative
Reasoning, and Smart Cars
In this thesis, context modeling methods and designs are presented and related to this
study. Before further describing the actual context modeling concept and the according
techniques, it is essential to provide information on comparable studies concerning
context modeling, as well as applied methods and techniques. First, a short overview over
context research, applications and the important question what context actually is, will be
presented. Then, an introduction to qualitative modeling and reasoning, used as a basis for
the work done on context modeling, is given. This is followed by a summary of prior work
on context-aware smart cars and runtime adaptation.
3.1 Defining Context and Context Awareness
The study has been conducted in relation to current research on self-adapting
software. In this case, self-adapting software describes software capable of adapting itself
according to current context situations. If self-adaptation is dependent on the system’s
context, it is known under the term context awareness. Before focusing on context
awareness and corresponding research, it is crucial to find a formal definition of context.
The term context derives from the Latin word contexto and literally means cohesion or
connection. In language as well as in computer science, context stands for a relation
between different entities, usually a relation between an entity and its state, behavior, or
location. In automotive applications, this could be interpreted as the connection of an
automobile with its surrounding. E.g. an automotive context can be defined as the location
of a car and how the location affects driving behavior. Since a car usually drives faster on
an interstate than in a city, the context would, in this case, influence velocity.
Considering our example car introduced in chapter two, we observe that the car and
its functions are influenced by context influences other than location and speed, e.g.
weather conditions, traffic or driver behavior. Thus, as suggested by [3] and [6] it does not
suffice to regard context as a mere representation of current state and location, but as an
infinitely larger set of variables that contribute to the car’s state and behavior.
Research on context-recognition and context-awareness uses a variety of different
definitions for context and context-awareness. Given the aim of this study, the following
was used as a working basis: G. Chen and D. Kotz define context in [7] as “… [a] set of
13
environment states and settings that either determine an application’s behavior or in which
an application event occurs and is interesting to the user”. Based on this description of
context we are now able to produce a more specific definition well suited for the present
purposes. Considering all influences on the system as a set of context variables vi, context
can be formally described, based on [8], as shown in (3.1).
( ) ( ) ( ) (3.1)
Feature selection and handling is a necessary part of context modeling, as shown in [3]
and [4]. A context model, also, should comprise constrains that allow or prohibit certain
relations between variables. Allowed relations, are all possible or likely combinations of
context variables, while prohibited relations are either impossible or highly unlikely. For
example, the combination rain and highway is allowed, while the combination tunnel and
rain would be regarded as impossible. This also includes possible or impossible
transitions between context situations. E.g. it is possible that a car leaves the interstate by
an exit and moves into a city and then parks somewhere. But it is improbable that the car
will park with a velocity above 30km/h. Moreover, certain characteristics of the variables
have to be taken into account for context modeling. Features cannot only be distinguished
by observability and influence on the car system but also by their update rate and their
temporal stability. I.e. some variables are static, like roads or traffic signs, some change
slowly, like weather conditions, and some are changing fast, like traffic. The dynamic or
update rate of contextual information also depends on the car’s speed as well as on the
means of data acquisition. Traffic information, for example, changes faster when obtained
by the car sensors, than, when obtained by the traffic radio or the Traffic Message Channel
(TMC).
The subsequent step after defining context is to pay attention to context awareness.
Context awareness basically describes the ability to recognize, to react to or to interact
with one’s context. B. Schilit et. al. propose a definition for context-awareness in [9] as
“context-aware systems adapt according to the location of use, the collection of nearby
people, hosts, and accessible devices, as well as the changes to such things over time. A system
with these capabilities can examine the computing environment and react to changes in the
environment”. This definition practically describes the corresponding requirements from
chapter two. Nevertheless, it is necessary to further determine the meaning of context-
awareness as done in chapter 4.2.
14
3.2 An Introduction to Context Modeling
In computer science, the term model is used for a formal representation of a real object
that allows performing inferences about the behavior of the object. Thus, a context model
is a reduced representation of a specific context. Using (3.1), the context model is a
representation of the variable vector V, defined in (3.2), that omits insignificant variables
to achieve a controllable complexity.
(3.2)
Keeping the main objective, reducing the energy consumption, in mind, we have to
model context as a set of context influences that allow or prohibit the usage of car
functions. While other studies on context-aware cars like [10] focus on short-lived
contextual information, like driving maneuvers, this study emphasizes more on medium
and long time influences like weather or surrounding. As suggested in [4], this requires
assessing context influences based on their impact, their stability, and their temporal
behavior. Thus, the importance of a context influence for a context model with
requirements R1 and R2 is given by its impact and its stability. Impact is determined by
examining if and to what extent an attribute influences car functions. Stability is measured
by the changing rate of the context influences. Features that constantly change, like driving
maneuvers, would require frequent configurations, resulting in large adaptation efforts
and are therefore ill-suited to fulfill R1. By choosing influences and defining context, the
two most important foundations for the desired context model are created.
Consequently, context modeling approaches have to be evaluated and analyzed related
to usefulness for the desired solution. [11] and [12] provide a comprehensive overview
over techniques and methods of context modeling. Both studies suggest criteria suited to
evaluate the usefulness of a context modeling approach. Criteria important to this specific
application are heterogeneity, imperfection, relationships, and efficient context provisioning.
Heterogeneity is especially important, as contextual information is vastly different in
content, update frequency, structure, and reliability. Comparing two important context
influences, speed and location, their dissimilarity is obvious. Speed is an unambiguous
influence that is effortlessly, and reliably observable in various ways. Location, on the
other hand, can be described in different ways, e.g. by road type or surrounding. It cannot
always be determined clearly and the means of measuring location, like GPS, are often
unreliable, and provide a varying precision. Imperfections of contextual information as
well as relationships between different context information and contexts attributes have,
as mentioned above significant influence for this application. Efficient context provisioning
15
describes the ability to inform the context-aware system efficiently about substantial
changes in the context. Other mentioned requirements, like reasoning, are of minor
importance in the focused application. Using the evaluation from [12] we observe that
Ontology-based models score well in heterogeneity as well as in relationship.
Ontology-based models offer a formal approach of gaining knowledge and describing
data based on ontologies. Ontologies are explicit formal specifications of terms and their
relations, as described in [13]. A basic example for ontology-based information from [11]
is shown in (3.3).
(3.3)
Major advantages, like a high level of formality and their efficient techniques to
describe relations, are shown in [11] and [13].
[11] suggests that both Object-Oriented and Ontology-based models perform well with
distributed data, as existing in car. Furthermore, both approaches are described to being
able to handle with incomplete data. Considering these evaluations, we conclude that
these modeling approaches are the most promising for our application. Other presented
approaches from [11], like Graphical Models or Key-Value Models, did not satisfy the
criteria mentioned above.
Object-Oriented (OO) models, apply paradigms from object-oriented software
development, like information hiding, encapsulation, and reusability to context modeling.
Furthermore, they offer formal interface specifications useful to encapsulate abstraction
layers and subcontexts. [14] presents a realization of an OO model. In this example,
context is divided into different context types, each with a different goal. Distinguished are
temporal, goal, spatial, and global context. Here, the OO paradigm is used to encapsulate
the different context types and to represent context as a set of classes. Findings from
chapter two support the usage of such paradigms, see [11]. Especially the paradigms
mentioned above are well suited for the goal of a platform –independent, modifiable
context management system, as they enable us to separate heterogeneous context
information from each other.
[12] suggests that many applications require a hybrid-approach based on multiple
context models methods. Applying and evaluating the models with methods from [11] and
[12], we conclude that an application specific approach based on the two options
mentioned above would offer the most benefits. OO modeling would provide
encapsulation and means to divide context into different categories, depending on the
16
different types of context information. This procedure will be similar to the one presented
in the example above. Ontology-based models offer a precise and formal context
representation that allows the specification of relationships. Hereby, as shown in the
example, we can define specific contextual information formally. The resulting model
would divide context into objects of similar content (context attributes), like weather or
traffic. The values of these objects are ontologies formally described as in (3.4). Here,
congestion is defined as any traffic state, where a car that is not parking, and not waiting at
the traffic lights is stopped or driving slowly on a highly populated street.
( ) (3.4)
Such a model would benefit from the formality and ability to describe relations of
ontology based models, as well as advantages of the OO paradigm.
As previously mentioned, formalizing the context model is imperative. Therefore, we
have to use formal description methods like shown in [15], [16], and proposed by J.
McCarthy in [17]. [17] offers a more generic notation for describing contexts or contextual
information. We use this notation mostly in the early stages of the modeling process to
describe the definition of context attributes and relations among them. Later on, we will
largely use the notation from [15].
3.3 Uncertainty in Context Modeling
Regarding the modeling of incorrect, imprecise and contradictory data, we compare
the present problem with other studies concerning the modeling of uncertainty in context
aware systems. [18] provides a comprehensive overview on dealing with uncertain
contexts. Promising approaches are Bayesian Networks, probabilistic and fuzzy logic, and
confidence values. [19] exploits a relational context model that handles uncertainty by a
probabilistic model. Bayesian Networks and similar techniques appear to be too complex
to be realized within the scope of this study, thus we decided to further examine the
usefulness of fuzzy logic and confidence values. Fuzzy logic would expand qualitative
regions by a fuzzy state near their borders. However, requirement R2 demands that the
provided information about the context state is unambiguous rather than fuzzy. Therefore
we concluded that membership functions may not be appropriate. Considering the options
mentioned above we reasoned that confidence values represent the most promising
approach to deal with uncertainty. To handle imprecise data close to interval borders we
use a straightforward confidence-based approach instead of fuzzy states close to
17
thresholds. If a context information value is close to threshold it remains in its previous
state until the confidence value positively supports moving to the adjacent state.
Confidence values also offer the possibility to make decisions in case of contradicting
context information. However, considering the heterogeneity of the utilized data it is
necessary to develop an application-specific approach for decision making, as described in
section 4.4.4.
The desired model has to run under real-time conditions and concerns several safety
related issues. Also, it includes a number of context information that are only significant
under certain conditions. Bearing both in mind, we do not want to increase computational
efforts by using these variables unless required. Thus, we have to develop a solution that
offers the possibility to include variables into the context model without using them
permanently. Since we decided to use Ontologies and thus relations based on First-Order-
Logic (FOL) we are now facing a formal problem, as FOL generally requires knowledge
about the state of all appearing atomic formulae. Hence, we decided to include an standard
value for complementary context attribute that is always valid if there is no indication that
the attribute is in a different state.
3.4 Methods of Qualitative Reasoning
After exploring requirements and approaches of context modeling we have to further
investigate context representation. As mentioned before, we need to develop a formal
description of context for a coarse-grain representation of a car’s environment. One very
promising option is Qualitative Modeling. Qualitative modeling is a methodology to
formalize intuitive knowledge and / or abstract first principle knowledge and numerical
models of the physical world, as described in [20] and [16]. It comprises developing
reasoning methods and computational models using such knowledge, see [20]. Its basic
concept is to represent knowledge qualitatively, i.e. mapping continuous values into
intervals and similar. By applying some of its methods and approaches, we are able to
design a context model that divides continuous physical values into meaningful regions.
This means portioning values into regions that affect the environment or the car
system in different ways. Splitting up values into significant areas is formally described in
[16]. P. Struss and M. Sachenbacher provide an algorithm to partition continuous values
into signification regions. By applying qualitative modeling and reasoning in context
modeling we are able to use a well-defined formal methodology and to reduce complexity
by avoiding context reasoning with continuous values. However, doing so introduces the
18
new issue of mapping quantitative values into qualitative regions. Thereby, we face the
issue of having imprecise quantitative values close to the borders of different qualitative
regions. This problem will be addressed along with handling imprecise, incorrect or
contradicting data in chapter 4.4.4.
Working based on qualitative reasoning created the need of a structured design
approach. In [21] and [22], B. Bredeweg et. al. offer such an approach. Their solution aims
at assisting the creation of qualitative models and simulation by offering a procedure
model including design considerations, documentation, and behavior analysis. The
approach consists of the following six steps:
1. Orientation and initial specification
2. System Selections and structural model
3. Global behavior
4. Detailed system structure and behavior
5. Implementation
6. Model Documentation
Chapter four will follow the suggestions by [21] loosely. Especially steps one to four will
be used for context modeling.
3.5 Context Awareness in Smart Cars
Context – awareness, as defined in chapter 3.1, has been applied to automotive
applications, particularly in Smart Cars, several times, for example in [10] and [23]. The
term smart car is not formally defined, but usually describes a car with advanced
electronic equipment, like ADASs.
An example with features similar to this study has been presented in [10]. Their study
aims at developing a system architecture for smart-cars from the perspective of context-
awareness. It features a context model similar to our own regarding the three-layered
architecture and the proposed data abstraction. Unlike this study, they do not aim at
reducing energy consumption, but rather at designing a generic context-awareness
platform for smart-cars. Thus, they do not investigate implications of reconfiguration.
Another interesting study by M. Madkour and A. Maach focuses on building an
ontology-based context model for context aware services in vehicles, as shown in [23].
Their study presents the realization of a pure ontology-based model. The purpose of their
model is quite similar to ours, as it aims at building a context-aware system that provides
services to the user dependent on the context. In contrast to this study, they obviously
19
have a different goal and, thus, different requirements regarding safety and reliability.
Furthermore, as they focus on user services rather than car functionality like driver
assistant systems, they work on a less hardware dependent abstraction level.
One important feature of this study is the representation of the environment in the
context model. Z. Papp et. al. propose a comprehensive world model in [24]. Their study
aims at providing cooperative intelligent vehicle systems with a global data sink for
knowledge about the local world, called Local Dynamic Map. Albeit, working on a very
different problem set, they faced several problems similar to ours, like representing a
large number of very different variables in an automotive environment.
A prior study by P. Klier at the Fraunhofer ESK deals with context - related self-
reconfiguration in [4]. The proposed self-adaptation is based on several configurations
based on a simple context model. Our study uses these configuration and context
situations as a basis for context representation. Furthermore, we aim at providing Klier’s
system with a sound definition and representation of context.
20
4. Design of a Context Model for Self-Adapting
Automotive Systems
The following chapter describes our work on context modeling in automotive
environments. In chapter two, we have given an overview on the present application as
well as a summary of the challenges faced. Furthermore, the requirements determined in
chapter 2.2 offer a good insight into goals and guidelines for the presented work. In
chapter three, we defined context, as given by (3.1), and determined our modeling
approach, based on previous studies on context modeling.
The consequential step, after defining context and reviewing context modeling, is to
proceed to applying the acquired knowledge on the objectives and problems. Our work on
formal context modeling as well as the resulting concept will be characterized in this
chapter. Furthermore, considerations on prospects and limitations of the proposed
concept will be described. The chapter begins by analyzing context in an automotive
surrounding and examining its connection with context-aware self-adaptation. The
following section treats the development of a formal method to choose context influences
for the context model. Afterwards, the context model as well as a procedure for context
verification is presented. Moreover, we present efforts and procedures to ensure
genericity, as described in R4. Finally, the chapter will conclude with an evaluation of the
resulting model.
4.1 Considerations on Context Modeling in Automotive
Environments
In view of the working definition (3.1) from chapter three, we want to apply the
context concept in an automotive environment. Thus, we have to consider several aspects
of the context in automotive environments. To begin with, we want to examine specific
context variables that significantly affect the automobile and the driving behavior. Such
context variables are called Context Influences. Here, it is intuitive to start by simply
regarding context variables that a car able to recognize. Figure 2 shows an exemplary
collection of context influences.
21
Car SystemWeather
Traffic Signs
Brightness
Velocity
Figure 2: Exemplary Context Influences
Observing these influences, it is noticeable that all of them either affect the behavior or
the activity of car functions, as shown in Table 1.
Table 1: Effect on Context Influences on Car Functions
Context Influence Effect on Car Function
Weather Activity and Intensity of Wipers
Velocity Activity ACC
Brightness Activity Beams
Traffic Signs Max. Speed ACC
Therefore, we can conclude that all of them are important aspects of automotive
context. But it is mandatory to determine if they are suitable and sufficient to control the
dynamic configuration of car functions. Hence, describing a generic approach to analyze
how a car function is affected is obligatory. By doing so, we gain a first insight into
selecting and specifying context influences.
Basically any behavior or activity change triggered by context influences can be
described as follows: The system observes a context influence, then considers its
implications and adapts the configuration or the state of the car function accordingly. For
example, the radar of the ACC measures that the vehicle ahead reduces its speed. To avoid
a collision and to maintain the desired distance the system has to reduce its own velocity
accordingly. An advanced system would base the speed correction also on the distance to
the vehicle behind.
22
Brightness / Daytime
LightsCar SystemSunset Turn on
Figure 3: Exemplary System Reaction to Changing Context
Considering, for example, the usage of the high beam, we notice that an average driver
will activate the high beam as long as they do not disturb other cars and as long as their
additional light is beneficial for his view. A similar reaction is shown in Figure 3. This
driver behavior roughly corresponds to the definition of context-awareness from 3.1.
Thus, it is the aim of this study to create an automotive context model that allows and
supports such context-aware behavior automatically. To obtain a context model, we first
have to further examine context influences and their direct and indirect impact on car
functions. In general, two points of impact have to be taken into account. To begin with, we
regard the direct limitation, i.e. the case that context influences prohibit the use of a
function. Second, we analyze the indirect limitation, i.e. context knowledge that informs
the system that the usage of the function is unadvisable, due to either hardware or safety
reasons. For example, the usage of the ACC, as specified in Appendix B, is directly
dependent on the influences Speed and Location. But its usage is also limited by other
context information like RainIntensity, which reduces precision and reliability of the radar.
This leads us to the conclusion that we have to deal with two different kinds of context
influences. One type that allows the usage of functions and one type, complementary to the
first that prohibits functions. The concrete definition of context information and context
attributes will be presented in section 4.3.2.
The challenge is then representation, structure, and values of the contextual
information. The specific representation is largely given by the design of the self-adaption
software, also called configuration manager. The design of the configuration manager
depends on architecture and abilities of the on-board E/E system. Furthermore, structure,
values, and granularity of context attributes depend on the affected car system as well as
on the car functions required to recognize the context. The required granularity will be
determined in chapters 4.3 along with the specification of context information and context
attributes.
To definitely determine specific attributes and their values, we need to consider the
existing car functions. The driver assistant systems selected for the example car are
presented in Appendix B. Furthermore, we provide a brief overview on manufacturer
dependent system variations. To this end, we describe variation points and notable
23
differences among different designs of the same assistant systems. A few variations of the
ACC are given in Table 2. The concept does hold in general, but naturally, not all existing
system variations can be shown within the scope of this work.
Table 2: Possible Variations of the ACC
Sensors Speed Range Restrictions
Radar (only front) 60km/h-180 km/h Ignores standing objects
Radar (front and back) 60 km/h -200 km/h Includes standing objects
Lidar (only front) 0 km/h -180 km/h
does not support Stop&Go
Lidar (front and back) supports Stop&Go
4.2 Defining and Analyzing Context - Based Self-Adaptation
A context-aware system, as defined in 3.1, is a system that is able to react to its context.
For the present problem, to react to a context means dynamically adjusting the
configuration of software functions in the car system. In the previous section, we
described the expected behavior of a context aware self-adaptation intuitively.
Distributed, embedded software functions require a number of resources, like ECUs,
busses, sensors, and actuators. Most of these resources consume energy depending on
their workload. On the other hand, they provide certain assistant functions to the car and
driver. Thus, context-awareness in this application serves two opposing aims: On the one
hand, reducing the number of active systems, and on the other hand, providing the driver
with the desired car functions. Figure 4 depicts the relationship between context and car
functionality. It is shown that the configuration manager bases its decision on the context
representation provided by the context manager. Functions on the other hand, require
specific context situations to operate.
24
Context Manager
Car FunctionsConfiguration
Manager
(De)activates Car Functions
Provides Context Representation
Is observed by
Require Context Situation
Context
Car System
Figure 4: Relationship Context and Car System
Based on this relation, we conclude that the operation of a car function is implied by
conjunctions of states of context influences C, as shown in (4.1).
( ) ( ) (4.1)
Based on (4.1), a configuration is implied by conjunctions of the operation of car
functions F, as shown in (4.2).
( ) (4.2)
Implication (4.1) is valid as long as the car function F is not (de)activated by the driver.
Thus, the configuration manager has to provide a user overwrite.
To achieve such a context aware system, it is imperative to thoroughly analyze the
relation between car functions and context situations. Before working on further details, a
precise system definition is required to distinguish between context and car system.
Having entities that cannot be allocated unambiguously to either the car system or context
would result in unnecessary difficulties for the formal context description. Hence, the first
step in analyzing the relationship between system and context is to draw an unequivocal
border between them. Based on the definition of context from above, we draw the
conclusion that the system consists of all hardware controlled by the self-adaptation
software as well as context manager and the self-adaptation software. All other involved
entities are context. This also includes the driver, since his actions, behavior and user
input significantly influence the car system. Therefore, the car system is the aggregate of
all functions and systems within the car that cannot influence the context significantly. For
this study, we assume that there are no relations or constrains between different car
25
functions, such as shared resources or mutually exclusive functions. The system definition
is depicted in Figure 5.
influences
DriverWeather
TrafficSurrounding
...
Car System
Context Manager
Configuration Manager
Provides Context Representation
Car Functions (HW)
Car Functions (SW)
controls
Configures
Figure 5: System Boundaries between Context and Car System
After analyzing context and system definition, we will take a closer look at the affected
car functions. As mentioned in 2.2, the number of car functions controlled by context and
configuration manager is limited due to the following issues brought up by R5: First, safety
is always of highest priority. Thus, car functions, contributing considerably to the safety of
a car and its passengers, like ESP, Airbag, or similar have to be omitted completely from
the configuration scope. Second, functions that usually are completely driver controlled,
like wipers or window lifters will also be omitted to avoid rejection by users due to the
restriction of their own direct control. Furthermore, functions or subsystems that
contribute to the context recognition, like sensors, have to be active whenever they are
required to observe possible changes in context. Finally, functions that are constantly
active, will not be taken into consideration, as well as functions, whose activity is
unaffected by context influences, like the infotainment system. The remaining functions,
which can be subjects to dynamic (de)activation, are mainly advanced driver assistant
systems.
These functions assist the driver in comparatively specific driving situations or
environments. Advanced driver assistant systems (ADAS) are relatively new in-vehicle
subsystems. The first systems were developed in the eighties and the early nineties of the
last century. Even though, being a recent trend, their numbers and capabilities have grown
vastly over the last twenty years. Several aspects make them ideal car functions for the
present study. These reasons are: Most of the ADASs are only required under specific
conditions, like the ACC on interstates of highways. Furthermore, most systems are not
required for driving, so it is not critical or dangerous if a system is not always available. A
26
major problem in analyzing the ADAS is that the particularities of these functions are
largely manufacturer-dependent. Moreover, the actual number and types of available
ADAS are equipment–dependent, too. Therefore, we will determine generic context
information and context attributes, suitable for different car variants. Nevertheless,
depending on the degree of deviation from our assumptions and the example car certain
changes in the context model are expectable. Expectable differences include the intervals
and the granularity of the qualitative values. E.g. for some cars it might be necessary to
recognize rain, other cars require the distinction between different degrees of rain. Section
4.4.5 provides procedures to implement such modifications. The presented procedures to
implement the context model for specific configurations are generalizations, based on our
observations made by analyzing the example car and specifying its context representation.
Before further proceeding we will introduce the example car. Table 3 shows an
overview on the ADAS included in the example cars, as well as on the used data sources.
Furthermore, appendix B provides a brief overview on the characteristics of the assistant
systems used for this study in the example car.
Table 3: Data Sources and Car Functions employed in the Example Car
Data Sources Car Functions
Front-Radar Adaptive Cruise Control
(ACC)
Back-Radar Blind Spot System (BSS)
Back-Radar in Mirrors Light Control System (LCS)
Front-Camera Lane Departure Warning
(LDW)
Rain Sensor Night Vision System (NVS)
Brightness Sensor Junction Assistant System
(JAS)
GPS-Based Geo Information System
Parking Assistant System (PAS)
Traffic Message Channel Traffic Sign Recognition (TSR) Weather News
4.3 Specifying Context Information and Context Attributes
The most important prerequisite for any context model is a thorough analysis of the
available context variables. In the following section, methods and procedures to select,
evaluate, and formalize variables for the context model will be presented. As sensors and
measuring methods depend on the car’s configuration and the manufacturer’s preferences
the observable variables and the precision of their values will vary for different
27
manufacturers and car types. Thus, the procedure to select and determine suitable context
influences has to be generic, so the determined context information and context attributes
are largely platform-independent. Furthermore, based on R4, context information and
context attributes have to be specified as generic as possible, so the model can be easily
applied to different systems.
To this end, we have to consider two major aspects. First, the context recognition shall
be designed according to the three abstraction levels of contextual information presented
in Figure 1. These abstraction levels guarantee that changes in data acquisition and in car
functions can be included without, or at least with little changing of context information.
Furthermore, the layered design allows to efficiently modifying layers without affecting
other layers.
Based on the abstraction levels presented, we conclude that a three-layered
architecture reflecting the three levels is most suitable. A basic design for such an
architecture is shown in Figure 6. The three layers will be allocated as follows:
Layer 1: The Data Layer will contain all raw or low-level data obtained by
sensors or other data sources
Layer 2: The Information Layer comprises platform–independent context
information, such as speed or brightness
Layer 3: The Context Layer contains context attributes. This layer will
inform the configuration manager is informed about the context
+forwardContext()+mapContextInformation()+getContextInformation()
ContextLayer
+getLowLevelData()+computeContextInformation()
InformationLayer
+getSensorData()
DataLayer
Figure 6: 3-Layered Architecture and Abstraction Layers
28
The different levels of data abstraction are shown in Figure 7. The figure depicts
the process to obtain context situations from raw data, and integrates the different
levels of data abstraction in the three-layered architecture from Figure 6
Context Situation
Context Attribute
Context Information
Raw Data
Data Processing
Value Mapping
Attribute Aggregation
Information Layer
Data Layer
Context Layer
Figure 7: Integration the Process of Data Abstraction in the 3-Layered Architecture
4.3.1 Selecting and Classifying Context Influences
Based on the definitions from 3.1 a car’s context is considered in our application, as a
relation between a variety of context influences that describe a car’s current environment
and state. Even though, context consists of an extremely large number of context variables,
we usually need only a fraction of these to describe the context sufficiently precise to
configure the car functions appropriately. Number and type of the required variables
depend on the actual goal of the context management system. A pre-crash system that
prepares the car for accidents would naturally require different contextual information
than a system that adapts the car’s infotainment services according to the surrounding.
Since the purpose of this study is to reduce computational efforts and energy consumption
29
of a car, we require context variables that impact operation and reliability of car functions.
With a formal representation of these variables it is possible to configure a car’s functions.
Before determining techniques for choosing influences it seems useful to further
classify them to reduce heterogeneity and thus complexity of the variable set. A
straightforward classification is done by examining how a variable influences a car
function. As explained above, we expect our context manager to act similarly to a driver
reacting to external influences. Therefore, classifying influences has to be preceded by
analyzing how influences affect car functions. In this case, we investigate the implications
of the relation between car functions and context influences. Afterwards, similarities
between different types of impact can be used as classification criteria. For example,
currently the availability of the ACC is controlled by the car’s velocity. The usage of the
ACC is only operational within a specified velocity range. But by taking a closer look at the
ACC system it is noticeable that the system is also affected by a number of other
influences: Rain, for example, can reduce the precision and reliability of the radar [28];
applying the system in inappropriate locations like cities or on construction sites is also
unadvisable. Thus, we classify context influences into a number of different, disjunctive
groups. The most suitable criteria obtained from analyzing the different impacts are listed
along with a few according context influences in Table 4.
Table 4: Classifying Exemplary Context Influences based on Impact
Criterion: Driving
Behavior Usability
Sensor reliability
Variables:
Traffic Density Location Weather Obstacles Velocity Daytime
Traffic Regulations
Another reason for classifying influences is to detect redundancies among them.
Redundancies are useful for context recognition and dealing with uncertainty, as they
provide additional evidence for the certainty of context information. Rain, for example, can
be detected by a simple rain sensor or the onboard camera. Other sensors are able to
determine the moisture of the road surface. If the rain sensor or the camera cannot clearly
detect rain, the system can double-check its results with the surface moisture. Based on
this redundancy, the two influences rain intensity and surface moisture could be grouped
together, as they both provide information about rain. Uncertainty and evidence will be
treated more detailed in chapter 4.4.4.
30
Now we have to take a closer look at the influences relevant for our application, and
how to determine them. A context model, as an abstraction of the real context, consists of a
reduced number of context variables. The remaining context influences have to suffice to
allow the required inferences about the context situation. Thus, the foremost challenge is
to identify the relevant influences along with a sufficiently fine-grained range of values.
The granularity of values will be specified in chapter 4.3.2.
Variables will be chosen depending on their relevance for the use case. In this study,
the relevance depends on the variable’s impact on the car’s functionality in a certain
context. For selecting relevant variables distinct criteria are required. Context information
can be classified in varies ways, like similarities in impact, number of affected car
functions, frequency of occurrence or changing rate.
These criteria can be used to determine the importance of context information for
configuring and examining the characteristics of context information. E.g. the surrounding
has a strong influence on the car, as driving behavior differs depending on whether the car
drives on an empty interstate with two lanes or through a construction site on an
interstate, where a lane is closed and the current lane is narrowed. In such a case, the
exact reasons for behavior changes have to be determined to allow selecting and
abstracting contextual information without losing important details. In the mentioned
example, the situation can be summarized as either free interstate or construction site,
since these descriptions already imply either a free road or restricted road conditions,
respectively. Further precision, like multiple or closed lanes do not provide relevant
additional knowledge about the situation. Thus, the context influences of the mentioned
situation important for our application are location, i.e. the car is on an interstate, and
construction site, i.e. driving and traffic are disturbed. This is depicted in Figure 8.
Inter-
state
Inter-
state
Construction Site
Free Inter
-state
Free Inter
-state
Inter-
state
Inter-
state
Construction Site
Figure 8: Abstracting relevant Information
The next criterion is the expected update rate of context influences, i.e. the frequency
in which its value changes distinctively. An influence that does not change during even a
31
long ride, like season or traffic regulations does not contribute to dynamic configuration,
for obvious reasons. Such influences have to be taken into account when designing the
context management system, but are completely irrelevant for our context model. On the
other hand, context influences that significantly change rapidly and constantly, like the
driving maneuvers described in [25], are also undesirable for self-adaptation as their
update rate could result in permanent configuration changes that would most likely
require large computational efforts than a static configuration. The only variable with a
high update frequency, selected for the context model is Velocity. Velocity has been
selected because of its extensive influence on several car functions and because most of
the frequent changes are within a limited, thus, insignificant, range. I.e. significant changes
are not frequent enough to present a problem in configuration. Table 5 shows selected
context information and their expected update rate.
Table 5: Update Rate of selected Context Information
Context Information Update Rate Location Medium Speed High Rain Intensity Low Surrounding Medium Traffic Density Medium
Another important aspect of external influences is their expected probability and
frequency of occurrence. While certain context information and their values will always be
available, e.g. speed or location, other influences only occur rarely, at specific times, or
under specific conditions. Snow in Germany, for example, is only likely in fall or winter,
and under specific requirements, such as temperature not significantly above freezing.
Other context information, like traffic density, are more likely to occur at rush hour and in
urban areas. Therefore, for the variable selection it has to be considered how often the
analyzed event is likely to happen. E.g. rain can be expected anytime in most countries
and, at least in Germany, it occurs frequently. On the other hand, smoke, blocking a
driver’s view, is a rather rare event. Thus, it seems reasonable to include frequent
influences into the context model and to ignore rare events, as their influence on R1,
reducing energy consumption, is marginal. Table 6 shows a range of representative
influences along with frequency of occurrence and prerequisite conditions.
Table 6: Influences with frequency and preconditions
Influence Frequency Required Conditions
Speed Always -
Location Always -
32
Rain Often -
Snow Seldom Winter / Temperature below Freezing
Tunnels Occasionally -
Darkness Regularly Tunnel or Rain or Night
Finally, it has to be ensured that the selected context influences can be measured
within a reasonable time and with sufficient precision and reliability. This is important for
handling uncertain or incorrect context information. Implications of dealing with
uncertain or missing data will be treated in chapter 4.4.4.
Summarizing the considerations from above, it has to be concluded that variables must
be chosen based on four major criteria:
Does the variable affect car functions?
Does the influence occur sufficiently frequent to contribute to R1?
How fast does the variable change?
Can the variable be measured in a reasonable time with sufficient precision?
Applying these criteria on an exemplary variable like location, we observe that
location influences most car functions, it is relatively stable, as location does not switch
between states like interstate or city permanently. Furthermore, location is always given
and does not have any preconditions. Finally, location can easily be determined by GPS or
other localization methods. Hence, we have shown that location is suitable for the context
model. Table 7 shows influences on the example car, which were selected based on the
criteria above.
Table 7: Variables selected for the example Context Model
Variable Affected Car
Functions Frequency of Occurrence
Update Rate Source
Location ACC, BSS, LDW, etc. Permanent Medium GPS / Camera
Velocity ACC, BSS, LDW, etc. Permanent High Tachometer /GPS
Construction Sites ACC, BSS, LDW, etc. Occasionally Medium Camera / TMC
Daytime NVS, TSR, JAS Regularly Slow
Clock / Brightness Sensor
Rain ACC, BSS, LDW, etc. Occasionally Slow Camera / Rain Sensor
33
Context information like the examples from Table 6 represents the content of the
Information Layer from Figure 6.
4.3.2 Abstracting Context Information
After determining how to analyze the characteristics of influences and to select
important variables for the context model, the consequential step is to further reduce and
abstract the set of variables, to guarantee larger hardware independence and to minimize
the complexity of the context model. More abstract data is required to provide the self-
adaptation efficiently with sufficient information to configure the car functions.
As mentioned before and depicted in Figure 6, the context model will be partitioned
into three layers to reduce the complexity of the context model and to achieve platform
and manufacturer independence. The Data Layer contains low level data and raw data
directly measured or received from the source. The Information Layer deals with context
information, like those in Table 6. It is usually determined or computed from the raw data
from the Data Layer. Context information used for configuration, called context attributes,
is gathered in the Context Layer. The layers of data abstraction, along with an example, are
presented in Figure 9. The purpose of this section is to map the contract information
obtained in the previous section into attributes. Context attributes are types or classes of
contextual information that are used to inform the configuration manager about important
aspects of the current context situation, for instance the weather condition. These context
attributes describe certain aspects of the context and have a small, defined number of
qualitative values. Further information on attributes is given in chapter 4.3.3.
Context Attribute
Context Information
Low Level Data
Weather:Rain
Rain
Rain Sensor Output
-> A
bst
ract
ion
->
Data Abstraction Example: Weather
Figure 9: Data Abstraction for the Context Model
A first step is to cluster variables, based on similar content. E.g., considering the
influences mentioned above, like rain, snow, and hail, they can all be used as values of a
34
context attribute called Weather. While this kind of abstraction is quite intuitive for
weather it is expectable that other context information is more difficult and less intuitive
to map. To this end, we take a close look at location and location-specific context
influences and attempt to determine one or more suitable context attributes. Cities,
motorways, interstates, or parking lots, are only a few locations, where a car can be.
Moreover, information about the surrounding, like junctions, adds even more complexity
to the concept of location and location-related context information. Thus, it is necessary to
find the distinctive aspects of location and to classify them, based on similarity. For a
driver, it usually does not matter, whether he drives through a forest or through fields,
unless it affects his driving behavior. Similarly, such information is only important for the
system configuration if it influences car functions like shown in Table 1. On the other hand,
driving behavior strongly depends on whether a car is on an interstate or in a city. The
same applies for self-adaptation, as some functions are exclusively designed interstates,
while others are only useful in cities. E.g., a junction assistant is of little use on interstates,
as interstate do not comprise junctions. Based on this, we conclude that location, as an
important context influence should be split in, at least, two different attributes. One of
these attributes, called Scenario, comprises the road type and implies certain aspects of
the road type, such as multiple lanes on interstates. The other attribute, called
Surrounding, describes other location-dependent influences that affect configuration, such
as constructions sites. The values of Surrounding are complementary to the Scenario, since
they provide additional information.
Road Type Position Obstacle Accident
Scenario
Interstate City
Surrounding
Accident Obstacle
Context Information describing
ubiquitous aspects of location
Context Information, describing
complementary aspects of location
Location-specific Context Information
Figure 10: Creating Context Attributes based on Location-Specific Context Information
35
Generally speaking, we want to cluster variable sets based on similar content and use
these clusters to create context attributes, based on the classification from Table 1. Figure
10 depicts the process of creating context attributes based on context information, as
explained above. Here, different context information, describing location, are grouped
based on their occurrence. Road Type and Position are context conformation that
ubiquitous, while Obstacles and Accidents are only encountered infrequently.
After mapping context information into attributes, further abstraction is needed to
determine their optimized granularity. This can be achieved by using the principles of
qualitative modeling, as described in chapter 3.4, thus mapping continuous values to
qualitative intervals. For example, velocity can be mapped into speed regions like slow,
medium or fast. In case of context information more abstract than velocity, it has to be
determined which details have to be omitted. In the construction site example above, the
situation description was reduced, since more precise information would not result in a
different configuration. Thus, the next step is to determine the granularity of the context
attributes. Based on our observations of how context influences affect configuration and
how variables can be characterized it is now relatively simple to determine the necessary
granularity. As shown in [16], we portion the variables into meaningful regions.
Hereby, we apply criteria similar to those for information selection from 4.3.1. Since,
we partly based our work on an exemplary generic system, comprising exemplary car
functions, and not with a specific real-world car, it is possible that the values of the
resulting context attributes and specifically the granularity of these values have to be
modified for a real-world implementation.
The obtained regions depend strongly on the car’s configuration and the parameters of
the car’s functionality, i.e. the number and type of the existing car functions, but also on
the differences in the functions themselves. For example, the typical Adaptive Cruise
Control (ACC) operates only for certain speed ranges, but there are also ACCs that work
for every possible speed. Table 8 shows likely intervals for speed and their relation with
the ACC and other ADAS functions.
Table 8: Significant Intervals for Velocity
Velocity [km/h] Designation ACC JAS PAS HDC
0 Stopped Disabled Available Available Disabled
30>=v>0 Slow Disabled Available Available Available
60>v>30 Medium Disabled Available Disabled Available
v>60 Fast Available Disabled Disabled Disabled
36
As previously mentioned we distinguish between ubiquitous and complementary
attributes. We assume that the system is always capable of identifying the Driving
Condition. Furthermore, we can assume that the value of Scenario can also be obtained at
almost any time, since GPS or other position finding methods usually work anywhere,
apart from the inside of buildings and tunnels. In such situations, the system should at
least be able to estimate or extrapolate position and scenario.
The other context attributes are only relevant for configuring the car functions if their
values influence the car functions. Thus, each of these attributes has to have one value that
describes that the attribute is currently not influences the configuration. Furthermore, I.e.
as long as we do not have any evidence that an attribute value is not in a state that
contributes to configuration, we conclude that the attribute does not influence the
configuration and set its value in the not-important state. Hereby, we can ignore the
attribute when informing the configuration manager about context situations, unless the
attribute state changes to another value. Table 9 contains attributes and their values, as
obtained for the example car. Here, it can be observed that a few intuitively important
values, like “Driving Reverse” for the Driving Condition are missing. The reason for this is
that the procedure described in Algorithms did not assess them as necessary. In case of
“Driving Reverse”, it has been concluded that the frequency of occurrence as well as the
duration of reverse driving are too low to be significant for self-adaptation.
Table 9: Context Attributes and Attribute Values of the Example Car
Scenario Driving Condition
Weather Condition
Visibility Condition Surrounding Traffic
Interstate Fast Clear Free Undisturbed Free
Highway Medium Rain/ Snow Dark
Construction Site Dense
City Slow Fog
Limited Accident/ Obstacle
Congestion Parking Stopped
Direct Sun / Too Bright
With these values it is now possible to describe the context precisely enough to
configure the car functions. The next important step is to define a formal description of
each attribute value as in (3.4). These definitions have to define attribute values
unambiguously and are given generically by (4.4) and as an example by (4.5). The value
definitions for the case study, presented in chapter 4.1, are shown in Appendix B.
(4.4)
37
( ) ( ) (4.5)
Finally, we have to analyze the completeness of the presented context representation.
Considering, the definition of context as an infinite set of variables, it is not feasible to
cover all existing influences. Possible ways to identify influences include, but are not
limited to, analyzing driving behavior, restrictions of car systems, causes for accidents or
legal restrictions. For the scope of this thesis, we consider the process as complete when
all identified influences on car functions are assessed.
To conclude this section, we want to summarize its results by presenting a generic
procedure to determine relevant context information and context attributes for any
concrete context manager, as shown in Algorithms 1.
Algorithm 1: Procedure to Determine Context Information relevant for our Application
Based on this procedure it is possible to select and specify context information and
context attributes suitable for different car and equipment types.
4.3.3 Analyzing and Specifying Context Situations
Before proceeding to designing the context manager, it is necessary to analyze and
relations between context attributes and possible transitions. Returning to the basic
definition of context from (3.1), we observe that the context influences are interrelated.
Certain context situations allow or prohibit other ones. Consequentially, these relations
have to be included in the context model. In (4.6), the model equivalent to (3.1) is shown.
( ) ( ) (4.6)
Furthermore, the transitions between attribute values as well as context situations
have to be further analyzed. Similar to the real-world, certain transitions and relations are
38
possible, others unlikely, and some impossible. E.g., the context manager has to observe
the transitions and to recognize impossible or improbable ones. If such transitions are
observed, the context manager has to inform the configuration manager about the
detected inconsistency to prevent self-adaptation based on erroneous data. Due to time
limitations, we examined context restrictions transitions only briefly. An example for a
restriction is given by (4.7).
(4.7)
4.4 Designing Context Model and Context Manager
Section 4.4 presents the creation of a generic context model and the context
management system (CMS). The CMS will be a software component for cars that gathers
relevant information presented by sensors, ECUs or external data sources and uses it to
determine the current context situation of the car. The resulting context situation is
checked for its consistency with the previous situation as well as the context restrictions.
When the current context situation has been determined and verified it will forwarded to
the configuration manager to configure the cars functionality accordingly. The creation of
model and manager is organized as follows. First, we develop a reliable and efficient
procedure to forward the context situation to the configuration manager. Afterwards, we
assess the desired system behavior and provide a structure for the CMS, comprising the
context model and the proposed architecture. This model will then be further refined to
fulfill the requirements from chapter 2.2. Subsequently, methods are presented and
proposed to handle incorrect or imprecise data. Furthermore, aggregating designs and
methods, a procedure to include new data sources or car functions in the context model
will be presented.
4.4.1 Defining Communication between the Context Manager and
Configuration Manager
In chapter 4.3 we specified variables and mapped context information to qualitative
values, called context attributes. The next step is to forward their content to the
configuration manager.
The attributes obtained by applying the procedures from chapter 4.3 to the example
car are shown in Table 9. With these attributes and their values it is possible to describe
the context situation sufficiently precise to allow situation-specific self-adaptation. Thus,
we conclude that requirement R2 is fulfilled as far as representing context is concerned.
Requirements R3 and R4 will be discussed in chapter 4.4.4 and 4.4.5, respectively.
39
Thus, the next issue for context modeling is to develop a straightforward approach to
inform the configuration manager about the current context situation as well as context
changes.
First, when the self-adaptive software is started, the CMS has to identify the current
context situation and then forward the information to the configuration manager.
Afterwards, the system has to continuously monitor the obtained context information. As
long as the context situation remains constant, it is not necessary to further forward
information. As soon as an attribute value has changed and the new context is verified the
new attribute state is send to the context manager, as shown in Figure 11.
Figure 11: Sequence Diagram Context Forwarding
4.4.2 Defining Structure and Behavior of the Context Manager
After selecting a suitable architecture as well as creating an application-specific
context representation, the next phase is to design the context manager.
The structure of the context manager shall comprise the proposed 3-layered
architecture from chapter 4.4.2 as well as the expected global behavior of the system. To
this end, we first have to analyze the expected behavior and capabilities of the context
manager. The main purpose of the context manager is to gather available context
information and to map them into context attributes containing information relevant for
our application. To achieve this purpose, the context manager is required to analyze the
obtained data, to provide means to map the data into the context attributes and forward
the attributes to the self-adaptation software. Furthermore, as we want to ensure the
correctness of the recognized context information and context attributes we want to
include a basic verification method into the global behavior. This method will compare the
observed context situation with the previous situations saved in the context history and
40
make prediction about likely and unlikely following situations. Context prediction itself
will not be covered in this study as it would exceed its scope. All these aspects of the
desired behavior are depicted in the concept map of Figure 12. In the concept map, the
entities of the application are shown as nodes, while their relations are shown as arcs, as
described in [22].
Context Manager
Raw Data
Context Information
Context Attributes
Context History
Context Prediction
Car FunctionsSelf-Adaption
Provides with Context Representation
Is based on
Are verified by
Are configured by
Car
Data Sources
Are provided by
Are provided by
Are provided by
Is derived from
Are mapped into
Is provided by
Driver
Is driven by
Is informed by
Figure 12: Concept map of the Context Manager
Based on this concept map we can obtain the basic structure shown in Figure 13.
41
ContextAttributes
ContextSituation
ContextPrediction DataAnalysis
DataSource
ContextRecognition
1
1
Successor
1
*
CarFunction
**
1*
**
1 *
*
*
*
*
Requires
Requires
PreventsPrevents
1*
* 1
Figure 13: Structure Context Manager
Based on this global structure we can obtain a specific structure for the context
recognition process, as shown in Figure 14.
42
+getSensorData()
DataLayer
+getContextInformation()+verifyContextInformation()
ContextInformation
+getLowLevelData()
DataProcessing
1
1
*
1
+getContextInformation()+mapContextInformation()+verifyAttributeValue()+sendAttributeValue()
ContextAttribute
1
*
+getContextInformation()+getContextHistory()+predictNextContext()
ContextPrediction
1 *
1
1
+getContextAttribute()
ContextHistory
1 *
1
1
Figure 14: Class Diagram for Context Recognition
Even though we did not treat context prediction within the scope of this study, we
want to provide a basic understanding on what context prediction is supposed to
comprise. Therefore, the temporal characteristics of context prediction are shown in
Figure 15.
Ct-n Ct-1... Ct0
Ct0
Ct0
Ct0
Context History
Context Prediction
Figure 15: Temporal Data Management
Based on designed structure we created a general design for the context manager as
shown in Figure 16. This structure is based on the developed abstraction layers and the
system architecture from the previous section. For this structure, the driver was ignored,
according to the system definition from chapter 3. Data sources and car functions were
merged into the entity car system.
43
Information Layer
Data Layer
Context Prediction
Context History Context AttributesProvide history
Predict following SituationsVerify Attributes
Abstract Data
Process Data
Self-AdaptationProvide Context
Car SystenProvide data
Configure Car Functions
Figure 16: Applying the Behavior Concept to the System Architecture
The behavior of the resulting system can be described as follows:
Data sources obtain new input (Data Acquisitions)
Obtained data is processed into context information (Data Processing)
Context information is mapped into attributes (Data Mapping)
The attribute value is compared to its previous state (Data Mapping)
A new attribute value is stored in the context history (Data Mapping)
If the attribute value has changed the change is transmitted to the self-adaptation
(Data Forwarding)
The new attribute value is used to predict the most likely following state (Context
Prediction)
The process of Data Mapping is shown in Algorithm 2. The other procedures were not
part of this study.
44
Algorithm 2: Data Mapping Process
4.4.3 Enhancing the Model to Verify Context and to Provide Fault
Tolerance
After specifying and formalizing relevant context information, context attributes, as
well as designing a generic context model the next phase is to enhance the model with
means to handle uncertainty. As noted in the previous chapters, uncertainty is ubiquitous
in technical systems. All data received by sensors or other sources is obtained with a
certain imprecision. Moreover, data processing can create further uncertainty by
quantization errors or similar cases. In addition, it is always possible that sensors are
disturbed or malfunctioning and, thus, provide faulty data. Imprecision and faulty data can
either lead to contradictory or incorrect context information. Especially incorrect context
information is strongly undesirable, as it may result in non-optimal system configurations.
Such configurations could increase the energy consumption and more critical distract the
driver, if functions are enabled or disabled without obvious reasons. Bearing in mind
requirements R3 and R5, we have to guarantee that the provided context information is as
precise and correct as possible.
To begin with, we want to give an overview on sources of uncertainty depending on
their abstraction level and present a process for context verification.
Data Layer: Faulty data or uncertainty occurring in the data layer can be due to
technical issues, like malfunctioning sensors and other hardware errors or sensor
imprecision. Data obtained from external sources, like traffic information, can be
45
faulty for similar reasons, or they can simply be outdated or falsely located. Traffic
or weather information is especially prone to these issues
Information Layer: Error sources in the information layer are mostly signal or
image processing algorithms or other data processing procedures. The second
important issue is contradictory data. This can be found in two different settings.
First, if a type of context information, like Velocity, is obtained by multiple sources
and then compared or merged. Second, when different types of context
information are compared for plausibility. In both cases, it is possible that the
compared data implies different values or states of context information. Moreover,
these problems can be worsened if the uncertainty of data sources is not being
handled beforehand
Context Layer: In the context layer, one major issue is contradictory context
attribute values. I.e. context situations in which attribute values are inconsistent
with their definitions. The second issue occurs during the value mapping process,
when the values of context information are close to interval borders.
All these issues have to be addressed to guarantee that the presented context model is
able to deal with uncertainty. Therefore, we present a process for providing a correct
context model with fault tolerance. The process does not include verification of sensor
data and data processing, as these actions are mainly hardware-dependent. Figure 17,
shows the proposed process.
Low Level Data has to be analyzed on continuity and plausibility to identify
possible sensor malfunctions
Before, or while, mapping data into qualitative values, the context
information has to be analyzed for its consistency and plausibility. Also, if
data is missing the system has to attempt to replace it with previous data or to
ensure that the context recognition is not impaired
For context attribute, is has to be verified that they are consistent with the
attribute value definitions
46
Context Situation
Context Attribute
Context Information
Raw Data
Data Processing
Value Mapping
Attribute AggregationVerify consistency
with Constrains
Verify consistency and plausibility
Verify continuity and plausibility
Figure 17: Context Verification Process
The first issue is unreliable and possibly incorrect data from the data level. The first
step is to verify the raw data received by sensors or other data sources, but this will be
done on the Data Layer (see Fig. 10) which is not covered by this study. Here we focus on
the verification of the processed data. Processed data means that we work with physical
values (e.g. speed or distance to other vehicles) instead of raw or indirect data (e.g. radar
runtime to measure distances). These data have to be checked on continuity and
plausibility. Verification on continuity can be handled straight-forward by identifying
jumps and similar inconsistencies. Ascertaining that the data is plausibly requires a more
complex approach. While implausible values can be tested with thresholds, implausible
behavior can only be detected by advanced algorithms. Such algorithms would exceed the
scope of this thesis and thus, will not be implemented during this study.
The next step is to analyze context information while or before mapping. For mapping
continuous values into qualitative values it is mandatory to verify that the system does not
map the values of context information into the wrong interval because of the inherent
imprecision. In chapter 4.3.2, we faced the challenge to handle context information values
close to interval boarders. To obtain more stable values we introduced overlapping
intervals. In these regions both adjacent values are valid. An attribute value only changes
once it leaves the overlapping regions into the other interval. This approach can also be
used to deal with uncertainty. To this end, the extent of the overlapping regions has to be
at least wide enough to cover the expected error margin of the variable.
47
In case that context information is obtained by different data sources it is possible that
the different values will not be mapped into the same intervals. Speed for example can be
measured by a number of very different sensors or data sources. Naturally, update rate,
precision, and reliability of the sources can vary drastically. Thus, it is expectable that the
obtained values from the different sources will not always be mapped into the same
qualitative regions. Even though we defined vague borders between different areas it is
possible that this problem will occur. If one of the data sources produces implausibility or
not continuous data, the system should be able to identify and to omit the faulty data and
to select the correct interval. But if both values are valid and consistent with other context
information it is necessary to determine the more likely interval. To this end, we introduce
two factors: Tendency and Evidence.
Tendency describes a factor that represents the current trend of context information.
I.e. is the value stable or is it changing. If the value is changing the trend shows its
tendency. To obtain Tendency straightforwardly we simply differentiate the values of the
preceding situations, as shown in (4.8). An approximation of the function f(vi) can be
gained by regression based curve fitting with the preceding values of vi., shown in (4.9).
For efficiency reasons, we propose linear curve fitting. Obviously, this is not applicable to
all context information due to their vast heterogeneity and the content of several
variables. Nevertheless, variables like Speed, Rain Intensity, distances between vehicles or
similar can be analyzed easily.
( )
(4.8)
( ) ( ) ( ) (4.9)
By applying Tendency, the system can now select the interval corresponding to the
current trend of the value of the context information. Furthermore, the Tendency factor
can also be used for short-term handling of missing data. Considering the following
example the effect of the new Tendency factor can be shown quite effortlessly. In case of a
malfunction of all data sources on visibility the system would check the previous states
and determine their tendency. Based on the tendency, the system is now in the position to
extrapolate the states and propose a current value for visibility. If there is no evidence for
a drastic short-term change of the content of the involved context information it is safe to
assume that the computed visibility is not significantly different from the actual one. But
naturally, this is only a short-term option, if it is possible that the sensor can be
reactivated. If not, it is probable that the corresponding car function has to be disabled.
48
Now we have to take the differences between the data sources into account before
planning a suitable decision making technique. For this purpose, we propose using a
confidence factor. Since this factor shall support and strengthen the evidence of the
correctness of context information for decision making it will be called Evidence factor.
This factor will represent the existing evidence for the correctness of context information.
To determine evidence we rely on static and dynamic factors. The following static
influences were proposed for the model: Precision of the data source and error rate of
signal processing or data interpretation. Dynamic influences are: values or context
dependent precision of the data source and other context information supporting certain
values. E.g. precision and reliability of the GPS systems depends on the number of
available satellites, thus the evidence for the location information would change
accordingly. Algorithm 3 shows the proposed procedure to choose between contradictory
context information based on Evidence and Tendency as implemented for the simulations.
Algorithm 3: Selecting Contradictory Context Information
In case of missing or incomplete data we have to look at two different possibilities. As
long as the Context Scenario and the Driving Condition are available, we can maintain a
rudimentary functionality. If the system should no longer be able to determine the
Scenario, for example because the navigation system fails, and, even worse the Driving
Condition, we have to change the configuration into a safe mode and inform the driver that
49
the system is not functioning anymore. Since all other attributes are merely optional and
refine the two mandatory attributes, our system must be able to cope with their absence,
but inform the driver about the problems. In case that the system can no longer determine
the Scenario, the context manager has to inform the system that it cannot provide a valid
context representation anymore. The self-adaptation software has to warn the driver and
switch the configuration into a safe default-state.
Further exploring our work on context verification we proceed to verifying context
situations. Here we face the challenge that despite our previous efforts it is possible,
though unlikely, that the recognized context attributes are not consistent with defined
restrictions, as shown in (4.7). Implication (4.11) shows that the presence of mutual
exclusive attribute values renders the context situation invalid.
( ) (4.10)
When the system notices an invalid context situation, it has to inform the configuration
manager about the problem. Context changes involved in the violation will not be
forwarded to the configuration manager before the problem is solved. Now the involved
context attributes have to be switched to the last consistent states until the problem is
solved. The configuration manager is responsible for switching the configuration of the car
functions into a safe mode or if that is not possible for safety reasons or similar, the driver
has to be informed that the context-based self-adaptation is currently disabled. The
challenge for the context manager is to determine a suitable context situation that is
consistent with the definitions and is as close to the current one as possible. Furthermore,
it has to identify the source of the inconsistency. As we did cover neither context
predication nor context restrictions in details, we did not further pursue this issue. The
current solution is that the context manager has to renew the attribute values in case of
inconsistencies. If refreshed data does not solve the inconsistency, we have to assume that
there is a problem in data acquisition and that, therefore, the context manager can no
longer provide services. For future applications, such inconsistencies might be solved by
more advanced methods based on the proposed context history and context prediction or
even an automatic diagnosis procedure. In that case the context manager would be able to
either maintain its operability if the problem is not permanent or to conclude that the
problem cannot be solved without maintenance more efficiently.
4.4.4 Ensuring and Evaluating Modifiability and Genericity
50
In this section, we explain why modifiability and genericity is required for context
modeling in automotive environment, along with examples for differences among
manufactures and cars. This will be followed by means and procedures applied to fulfill
requirement R4. Afterwards, the genericity of the resulting model is presented by
modifying an exemplary car function and implementing changes on the model.
As mentioned in the previous sections, the actual car system and, thus, the context
model, depends on a variety of factors and variations. The most important differences are:
Applied technologies, depending on the manufacturer (e.g. using radar or
lidar for measuring distance)
Equipment installed in the car, depending on customer and manufacturer
Characteristics of data sources and car functions, depending on industrial
standards, legal directives
These factors have to be taken into account when implementing the context manager
for a specific car. Furthermore, it has to be expected that already implemented context
models will be modified, by either adding or removing car functions.
To realize a model that fulfills R4 and includes all the variations mentioned above it is
necessary not only to provide methods to implement a solution but also to create
procedures to modify and adapt it. In the previous sections, we developed means to
generically design a context model. Furthermore, we designed the architecture of the
context manager according to object-oriented paradigms that support modifiability, such
as a layered architecture.
51
Based on our work to design the context model we defined a procedure, depicted in
Algorithm 4, to adapt the context model to changes in equipment or data sources.
Algorithm 4: Procedure to Include New Car Functions or Data Sources
52
Analyze Modification
Analyze Implications
Are Data Sources Affected
Are Car Functions Affected
Is Information Gained or Lost
Is different Information
required
yes yes
New Car Function
Conduct Changes
Analyze ImplicationsFor the Information
Layer
yesyes
No Changes in Context Layer
Analyze Implications
noNo Changes in Data
Layerno
Are Changes required
yes
No Changes in Data Layer
noNo Changes in Context Layer
Figure 18: Procedure to Analyze Impact of Different Car Functions
To illustrate the proposed procedure, we want to apply it to our example car use
case, by replacing an ADAS with another version. Therefore, we introduce a new system
which is a modified version of the ACC. Unlike the previous one, it is suitable for cities and
velocities above 30km/h. However, due to safety reasons, an upper limit for the speed
range of 160km/h was introduced. Moreover, the radar was replaced with a Light
Detection and Ranging (Lidar) device, which offers higher precision and longer ranges.
53
Furthermore, the new sensor is able to support the camera in identifying objects, such as
pedestrians, and in observing the traffic situation. But the sensor is still unreliable under
bad weather conditions. Unlike radar, it does not work reliably in presents of fog or
smoke.
To modify the context model accordingly, we have to analyze the implications of the
new abilities and the new sensor of the system. To this end, we start be recalling the
definition of the usability of the ACC in (4.11).
( )
( )
(4.11)
The major difference in this example is the modified speed range. According to the
methods proposed in chapter 4.3.1 and 4.3.2 we adapt the values of the attribute Driving
Condition as shown in Table 10. The upper limit for the usability of the ACC can easily be
included into the attribute. The definitions of other car functions have to be extended by
this new value. As other functions are not affected by the new value, the only required
effort is to include the new value into their definitions. For future applications based on
software product line engineering, it has to be determined if it would require less effort to
standardly provide different variants of the context model with different granularities to
be prepared for such changes.
Table 10: Modified Values for Driving Conditions
Velocity [km/h] Designation ACC 0 Stopped Disabled 30>=v>0 Slow Available 60>v>30 Medium Available 160>=v>60 Fast Available v>160 Very Fast Disabled
In consequence, the new implication of usability of the ACC is given by (4.12):
( ) (
)
( ) (4.12)
The next step is to determine implications of the new sensor. It is necessary to assess
which context information, context attributes, and car functions are affected by the
change. Among the affected context information is the traffic density, which can be
estimated more precisely now, as well as the recognition of objects that also profits from
54
the higher precision. These differences affect only the evidence factor of these data
sources, but do not result in larger changes to the context model.
None of the mentioned changes above did affect the Information layer. Moreover, it
was shown that modifications can be easily implemented without larger changes in the
context model.
4.5 Discussion
The purpose of this section is to summarize and evaluate work and results of the
previous sections. First, we want to give an overview on the obtained solution, followed by
a comparison of the resulting solution and the requirements from chapter 2.2. The
fulfillment of the requirements is given in Table 11.
In chapter four, we created a generic context model capable to inform a configuration
manager about significant context influences. The resulting model comprises a three-
layered architecture for different levels of data abstraction, means to recognize relevant
aspects of context and to represent them. Context model and representation is based on
object-oriented and ontology-based context modeling methods analyzed in chapter three.
Table 11: Status of Requirements
Requirement Solution Status R1 – Reducing energy consumption and computational efforts
Variables have been chosen based on the effect on car functionality;
To be determined in chapter 5
R2 – Recognizing and Representing Context for R1
Context manager is capable of abstracting and aggregating context information and representing it in context attributes; the attribute values are based on qualitative modeling to reduce complexity and to allow an efficient representation
Requirement fulfilled, final evaluation has to be based on simulation in chapter 5
R3 – Handling faulty data and uncertainty
Data is verified in all abstraction layers; Context information has to be supported by evidence and tendencies;
Requirement fulfilled
R4 – Providing guidelines and procedures to achieve modularity
Procedures for selecting variables and adapting the context model depending of different manufacturers or equipment have been presented
Requirement fulfilled
R5 – Guaranteeing Safety critical function have Requirement partly
55
functional safety and real-time capability
been omitted from self-adaptation; context recognition is designed to yield in robust context situations, to avoid frequent configuration changes; context model and context recognition are designed to be simple and efficient;
fulfilled; Safety is guaranteed, but cannot be simulated. Real-time capability was only used as a guideline and has to be verified in a concrete implementation
56
5. Design Evaluation and Simulations of an
Exemplary Car System
To exploit the concept and to evaluate the possibility of reducing the energy
consumption, we created an implementation for the context manager in a simulator. The
following chapter describes the implementation of the simulated system, the details of the
simulated car system and addressed issues, like average driving profiles. Furthermore, the
simulations and their evaluation will be presented.
5.1 Considerations on Model Evaluation and Simulation
The purpose of the simulations described in the following sections is to apply and
evaluate the design proposed in chapter four.
For the simulations, we used the example car introduced in the previous chapters. The
car system includes a number of sensors, and advanced driver assistant systems, as shown
in Table 3. The concrete equipment is shown in Appendix B. Since we do not model the
actual functionality we reduce the car functions to rudimentary objects that compute their
activity based on the recognized context situation. Since the configuration adaptation of
the software functions themself is not part of this work we used a very simple
reconfiguration system that enables or disables functions depending on their usability. To
determine the usability of a car function, we implemented the usage implications as
described in (4.1). The definitions of usability are given in the Exemplary Car Functions
section in Appendix B. The car functions monitor their activity and forward this
information to the evaluation.
Before proceeding to the implementation of the context manager and the car system,
we have to define the settings for the simulations. The first major issue is to define suitable
environment parameters and test data for the simulations. As the configuration of the car
system depends on the recognized context, the outcome of the simulations will largely
depend on the provided context information. Instead of defining an arbitrary test route
we want to provide the simulations with random data disturbed according to defined
probabilities. For example, car manufactures calculate the fuel consumption of cars based
on a distribution called Norm cycle, see [27]. The norm cycle consists of 33% city, 33%
highway, and 33% interstate. As it is regarded as a quasi-standard, we will use this as
basis for the simulations. Other simulated context information will be based on its
57
frequency of occurrence. In the test, the frequency will be increased stepwise over a series
of tests to ascertain the impact of each influence. Velocity, and, hence, the Driving
Condition will depend upon the other variables, as it is naturally in the real world. I.e. a car
drives faster on an interstate than in a city and slower during a thunderstorm than on a
clear day.
After executing the simulations the effectiveness of the introduced context manager
will be determined in terms of the reduction of the average number of active car functions.
Furthermore, we will evaluate the specific influence on the activity of single car functions.
5.2 Design of an Exemplary Automotive System and its Architecture
The implementation of the context manager was based on the design proposed in
chapter four. To create a realistic car system we used the car functions specified in
Appendix B. The implemented context attributes are based on these car functions and
were obtained, as described in chapter 4.3.2.
One major obstacle was that no configuration tool was available. Therefore, we had to
create a simple implementation based on the specific usage criteria of the car functions.
We used the implication from (4.1) as a working basis and implemented car functions
which would only be active if these implications are valid, see, for example, in (5.1).
( ) ( )
( ) ( ) (5.1)
The implemented context manager is designed as shown in Figure 19. We use as
sensor data were either continuous values, e.g. for speed and distance to other vehicles, or
discrete values, e.g. for the weather and traffic news. The obtained context information
was mapped into qualitative values according to our work in chapter 4 and the attribute
specifications from Appendix B.
As we did not further explore context prediction and context history for this thesis, we
will mostly omit these parts from the simulations. Furthermore, we did not implement a
dynamic assessment of the evidence factor, as this falls beyond the simulation scope which
is to show the feasibility and the potential of the proposed design. For further research,
context prediction might offer a possibility to increase reliability and accuracy of context
recognition.
58
ContextManager
TestDataGenerator
ConcreteAttribute
AbstractAttribute
ConcreteCarFunction
AbstractCarFunction
RandomNumberGenerator
1
*
1
*
1
1
Figure 19: ClassDiagramm ContextManager
To obtain a manageable system within the given amount of time we implemented the
main aspects of the context model introduced in this work. First of all, we reduced the
evidence based approached as well as the tendency factor. The factors were not left out
completely. Instead of dynamically determining evidence we used a static value based on
precision and reliability of the sensors. The Tendency factor, the context history and
prediction were merged into a single process that, in case of uncertainty, preferred the
value more likely based on its previous states. Furthermore, we did not implement
influences of context situations on sensors or sensor reliability, as this would have
increased complexity drastically without offering additional information on the systems
performance nor increasing the quality of the simulation results.
The system was implemented within a simulation framework of the Fraunhofer ESK,
called DynaSim. The implementation language was C++ along with the class library
SystemC.
SystemC is a modeling and simulation class library for C++, as described in
DynaSim is a simulation framework developed by the Fraunhofer ESK and
implemented in C++ with SystemC. The purpose of DynaSim is the simulation of
static and dynamic (automotive) software architectures, see [2]
59
5.3 Simulations and Performance Evaluation
After implementing the example context manager and designing the test system, the
following issue is to determine the simulation parameters. The obtained results are
presented in Appendix C. As mentioned in 5.1, we use the norm cycle as a basis. The
generated sensor data will be following a Gaussian distribution. The influence of the
frequency of occurrence of context values will be determined by increasing it stepwise for
each context value. Figure 20 shows the influence of the driving style and thus, the average
velocity, on function activity. Here, we can observe that an increased average speed leads
to a higher usage of ADAS. This concurs with our expectations, as a majority of the
simulated car functions is only available at higher velocities. Based on our survey on which
functions are influenced by which context attributes, we can assume that this correlation
also applies for the Scenario. I.e. if the car drives more frequently on an interstate than in a
city, the average number of active functions increases.
Figure 20: Function Activity based on the driving style
The next step is to analyze the impact of the frequency of occurrence of the remaining
context attribute values. Figure 21 shows the impact of the likelihood of rain on the car
function’s activity. Here, it can be seen that, while the average number of active functions
decreases with an increase likelihood of rain, this effect is inverted for certain car
functions. In the shown example, the activity of the Light Control System (LCS) drastically
increases. The reason for this is that the LCS is not only activated at nighttime, but also
under bad weather or visibility conditions. Thus, more rain implies a higher activity rate
for the LCS. On the other hand, functions like the ACC or the Blind Spot System (BSS) have
2
2,5
3
3,5
0
5
10
15
20
25
30
35
40
45
50
Very Slow Slow Medium Fast Very Fast
Nu
mb
er
of
acti
ve F
un
ctio
ns
Fun
ctio
n A
ctiv
ity
[%]
ACC LDW Average Active Functions
60
to be disabled more often under bad weather conditions, as their sensors become less
reliable.
Figure 21: Functions activity dependent on likelihood of rain
The subsequent step is to proceed to analyzing the effectiveness of the context
manager. To this end, we compared the function activity of three different types of self -
adaptation. For these simulations we used frequencies of occurrence based on the
simulations shown in Appendix C .
1. First, we used a conservative approach, were functions are only enabled or
disabled depending on single variables. I.e., the ACC was active as long as the
car was faster than 60km/h, the Night Vision System (NVS) was active in
darkness, and the Parking Assistant System (PAS) was active when the driver
activated it.
2. Second, we extended the first system with a very basic context model only
consisting of Velocity and Scenario
3. Finally, we simulated the actual context manager, as developed in this study
The results of these simulations are presented in Table 12 and Figure 22. They clearly
show that the activity rate for all simulated car functions decreased with the use of the
context model. The same effect, but with a lower magnitude, can be observed for the
location-based self-adaptation. All in all we measured a 24% reduction compared to the
traditional system, and 12% reduction compared to the solely location-based self-
adaptation. Based on this fact, it has to be concluded that a context-based self-adaptation
would still be capable of reducing function activity if none of non-permanent attributes
2,5
2,6
2,7
2,8
2,9
3
0
10
20
30
40
50
60
70
0% 5% 15% 30% 50%
Nu
mb
er
of
Act
ive
Fu
nct
ion
s
Fun
ctio
n A
ctiv
ity
[%]
ACC LCS Average Active Functions
61
occurs during a drive. Regarding the tendencies observed when analyzing the impact of
different frequencies of occurrence, we also can conclude that the resulting reduction of
function activity will increase for lower frequencies until it approaches the function
activity of a purely location-based system.
Table 12: Reduction of Function Activity in Percent Depending on Self-Adaptation Type
Self-Adaptation Type Non Location-based Context-based
ACC 55 38 29
BSS 55 54 45
LDW 55 54 41
LCS 24 23 23
PAS 3 1 1
JAS 32 22 19
NVS 23 15 11
TSR 100 96 95
Average 3,5 3,1 2,7
Min 1 0 0
Max 8 7 7
Figure 22: Function Activity depending on Self-Adaptation Mode
5.4 Discussion and Concept Evaluation
In the last chapter, the simulations based of the proposed context manager were
described. Hereby, we are able to determine an estimation of the potential of our
presented design. Comparing a not context based function activity, and the average
activity achieved by applying the context manager we obtained a reduction in the average
2,5
3
3,5
4
0
10
20
30
40
50
60
Non Location-based Context-Based
Nu
mb
er
of
Act
ive
Fu
nct
ion
s
Fun
cto
n A
ctiv
ity
[%]
Activity ACC [%] Average Active Functions
62
function activity of 24%. Thus, we were able to show that our context model is suitable for
providing that the configuration manager with a context representation to fulfill R1. But
considering the observed differences in function activity due to changes in the frequency
of occurrence, we have to conclude that the measured reduction has to be regarded more
as a point of reference than a tangible value. One restriction of our simulations was that
we could not provide a reliable measurement for the occurring overhead and additional
energy consumption due to configuration changes. Furthermore, we can only provide a
qualitative result by measuring the activity of functions, and do not make any assumptions
on the differences in energy consumption and computational efforts between the specific
car functions.
Based on the results from the simulations, we are able to assess the concept developed
within the scope of this study, with respect to the requirements from chapter 2.2.
R1 – As shown in chapter five, the simulated context manager was able to reduce
the average activity of car functions by 24%. Thus, it can be assumed that the
average energy consumption of the involved car functions was reduced by a
comparable level, depending on the additional consumption of overhead, due to
the context manager and the configuration changes. Thus, we conclude that the
requirement is satisfied
R2 – In chapter four, we created a generic context model for the dynamic
configuration of car functions to the end described by R1. The resulting model
comprises methods to select and specify context information and context
attributes relevant to the mentioned purpose. Furthermore, the model is designed
to recognize and represent context situations and to verify their correctness. Since
the model satisfies requirements R1, R3, and R4, we assume that it fulfills the
specifications of R2
R3 – The solution developed in chapter four was specifically designed to cope with
uncertainty in context information and with faulty context attributes in context
situations. In chapter 4.4.4, we introduced methods to verify context and to handle
incorrect and incomplete context information. The resulting solution consists of
techniques to solve contradictory context information as well as imprecise and
unreliable data. In addition, we proposed a process to ascertain contextual
information in every layer, from data acquisition to the context attributes, thus R3
has been satisfied
R4 - In chapter 4.4.4, procedures and guidelines for achieving genericity and
modifiability were presented. Based on the example modification in 4.4.4 it was
63
shown that the context model can easily be adapted to different car systems.
Therefore, the requirement is satisfied within the scope of this study. Nevertheless,
for future applications, it is recommendable introduce a context framework, based
on principles of Software Product Line Engineering that allows the fast and simple
implementation of the context manager for different variants.
R5 - During the design of the context model and context manager, all decisions
were based on the guideline that the resulting system has to work under safety-
critical real-time conditions. Based on this, we attempted to reduce the number of
variables as well as the number of their values. Furthermore, we designed context
verification and value mapping as simple as possible, to avoid unnecessary
computing efforts. Considering the functional safety of the context manager and
the involved car, we exempted safety-critical functions from the scope of the
dynamic configuration and attempted to guarantee that context-based
configuration changes were conducted as rare as possible and that the resulting
configuration never occurred in dangerous situations. As it was not possible to
simulate and to evaluate this behavior we conclude that R5 is only fulfilled as far as
the scope of this study is concerned. Future work has to verify that the model
complies with safety and real-time standards
64
6. Concluding Remarks and Future Work
In the scope of this thesis, a concept for context modeling in automotive applications
has been proposed and evaluated. Among the achievements are procedures to determine
suitable context variables for context models, a context representation adjusted to
providing self-adapting software with sufficient information to dynamically configure the
car system. Furthermore, the resulting context model was designed to handle uncertainty
and incorrect, contradictory, or imprecise information. Finally, a procedure to implement
the model for different car variants has been presented.
To prove the feasibility and the effectiveness of the presented design, a basic
implementation was simulated on an example car system. With these simulations we were
able to show that the solution is capable of reducing function activity and, therefore,
computational efforts in car systems.
Following this study, it is necessary to further pursue the evaluation and refinement of
the proposed design for more realistic settings. Therefore, the consequential step is to
implement the context manager for a more detailed and more sophisticated simulation
setting, or in a real car system. The latter option would obviously be the preferable
solution, but it suffers from the major drawback that current cars do usually not comprise
self-adapting architectures. In case of further simulations, it would be advisable to include
actual sensors and data sources as well as a more detailed system architecture to refine
context verification and recognition on real-world data.
Considering the difficulties in verifying context, like obtaining sufficient evidence or
tendencies for context information, additional research on context prediction for self-
adaptation in cars has to be conducted. Context prediction based on Markov Chains or
Bayesian Networks seems to be a good approach for extending this approach to further
strengthen evidence for recognized context situations.
65
Bibliography
[1] M. Broy et. al., “Engineering Automotive Software,” Proceedings of the IEEE, 2007
[2] M. Zeller et. al., “Co-simulation of adaptive automotive embedded systems,” Presentation
held at IEEE / IFIP International Conference on Embedded and Ubiquitous Computing
(EUC), 11.-13.12.2010, Hong Kong
[3] A. Schmidt et. al., „There is more to Context than Location,“ Computers & Graphics, 1999
[4] D. Nicklas, “Context modeling and resoning,” 2007, University of Stuttgart
[5] P. Klier, “Modellierung von Laufzeit-Adaptivität im Bereich Automotive,” Fraunhofer
ESK, 2012
[6] P. Dourish, “What we talk about when we talk about context,” Personal and ubiquitous
computing, 2004
[7] G. Chen and D. Kotz, “A Survey of Context-Aware Mobile Computing Research” IEEE,
2000
[8] P. Struss, “Modellbasierte System und qualitative Modellierung,” Model-Based Systems &
Qualitative Reasoning, Technische Universität München
[9] B. Schilit et. al., “Context-aware computing applications” Mobile Computing Systems
and Applications, 1994
[10] J. Sun et. al., “Context-Aware smart car: from model to prototype,” Journal of Zhejiang
University-Science A, 2009
[11] T. Strang and C. Linnhoff-Popien, “A Context Modeling Survey,” UbiComp 2004
[12] C. Bettini et. Al., “A survey of context modeling and reasoning techniques,” Pervasive
and Mobile Computing, Volume 6, Issue 2, April 2010
[13] R. Krummenacher et. T. Strang, “Ontology-Based Context Modeling,” Workshop on
Context-Aware Proactive Systems, 2007
[14] B. Bouzy et. T. Cazenave, “Using the Object Oriented Paradigm to Model Context in
Computer Go”, Proceedins of the First Interational and Interdisciplinary Conference on
Modeling and Using Context
[15] P. Struss, “Modellbasierte Systeme und qualitative Modellierung,” Kapitel 12 xxx
66
[16] P. Struss et. M. Sachenbacher, “Significant Distinctions Only: Context-dependent
Automated Qualitative Modeling,” 13th International Workshop on Qualitative Reasoning,
1999
[17] J. McCarthy, “Notes on Formalizing Context,” Proceedings of IJCAI-93, 1993
[18] A. Ranganathan, “Reasoning about Uncertain Contexts in Pervasive Computing
Environments,” Pervasive Computing, 2004
[19] B. A. Truong et. al., “Modeling Uncertainty in Context-Aware Computing,” Computer
and Information Science, 2005
[20] K. D. Forbus, “An Introduction to Qualitative Modeling,” Northwestern University,
2003
[21] B. Bredeweg et. al., “Towards a structured approach to building qualitative reasoning
models and simulations,” Ecological Informatics 3, 2008
[22] B. Bredeweg et. al., “Towards a Structured approach to Qualitative Modeling,“
Proceedings of the 3rd Model Based System Workshop, 2006
[23] M. Madkour et. A. Maach, “Ontology-based context modeling for Vehicle Context Aware
Services,” Journal of Theoretical and Applied Information Technology, 2011
[24] Z. Papp et. al., “World Modeling for Cooperative Intelligent Vehicles,” 2008 IEEE
Intelligent Vehicles Symposium, 2008
[25] M. Trapp, “Modeling the Adaptation Behavior of Adaptive Embedded Systems”,
Dissertation Technische Universität Kaiserslautern, 2005
[26] K. Pohl et. al., “Software Product Line Engineering –Foundations, Principals, and
Techniques”, Springer Verlag Berlin Heidelberg, 2005
[27] DIN 70030-2 “Kraftfahrzeuge, Ermittlung des Kraftstoffverbrauchs; Lastkraftwagen
und Kraftomnibusse,“ 1986
[28] J. Helmert et. J. Marx, “Schneller als Gedanken: Blickbewegungen bei Gefahr,”
Technische Universität Dresden
67
Appendix A
Glossary
Context The Context C is the environment and state of the system. It consists
of an infinite set of observable and unobservable variables v, that
describe the current state, behavior and surrounding of a system.
Context is given by the relation of these variables, as given by A.1
CA = DOM(v1)xDOM(v2)xDOM(vn) (A.1)
Context Model The Context Model is a model for an automotive Context consisting
of Context Attributes representing Context Influences relevant for
the application. The context model is used as basis for the
configuration of the car functions. The design of the context model
is modular, so further context information can be added as
required.
Context Variable A Context Variable is any variable within the cars context
Context Influence Context Influences are Context Variables that influence the car
functions in any measurable way
Contextual Information The expression Contextual Information describes obtained
information about the context independent of the abstraction level
of the information
Low Level Data This expression describes Contextual Information in the Data Layer
of the Context Manager. Low Level Data is obtained by data sources
and, therefore, hardware-dependent
Context Information Context Information is the designation for platform-independent
Contextual Information represented in the Information Layer
Context Attribute Context Attributes, or short attributes, is the formal representation
of Contextual Information in the Context Layer of the Context
Manager. Attributes describe certain aspects of context in an
abstract, formal way. The value of a Context Attribute is given by a
distinct relation of Context Information.
68
Context Situation A Context Situation is the state of context or context model at a
precise moment in time, given by CMtn
Car System The Car System is defined as the system of E/E functions and
involved software within a car. The term only addresses functions
that can be controlled by the Context Manager
Configuration also called Self-Adaptation System, is the software component
Manager responsible for adapting the system according to the current
Context Situation provided by the Context Manager
They are the only context information used for notifying the self-
adaptation system about context situations.
Context Manager Context Manager or Context Management System describes the
software responsible for collecting context information, recognizing
and verifying contexts, and informing the self-adaptation system
about the current context.
Context History The Context History is a data sink for previous Context Situations.
(CH = {CMtn-2, CMtn-1, CMtn}). The Context History can be used to either
verify context information or to predict upcoming context
situations, see Context Prediction
Context Prediction Context Prediction is a concept used to determine the most likely
future Context Situations (CMtn -> CMtn+1), as well as to strengthen
Evidence in case of new, contradicting context information. Context
Prediction way only suggested as a concept within the scope of this
study and not further developed
Evidence Evidence is a factor determined on precision and reliability of a
context information. It is used for decision making in case of
imprecise or contradictory data
Tendency Tendency is a factor determined on the trend of context
information. It is used to strengthen Evidence for context
information based on the extrapolation of the previous values
List of Abbreviations
ACC Adaptive Cruise Control
ADAS Advanced Driver Assistant System
69
BSS Blind Spot System
C2I Car to Infrastructure
C2X Car to X Communication
CMS Context Management System
EAST-ADL Electronic Architecture and Software Technology – Architecture
Description Language
ECU Electronic Control Unit
ESP Elektronisches Stabilitätsprogramm (Electronic Stability Control)
GPS Global Positioning System
HMI Human – Machine - Interface
JAS Junction Assistant System
LDW Lane Departure Warning
NVS Night Vision System
PAS Parking Assistant System
TSR Traffic Sign Recognition
UML Unified Modeling Language
70
APPENDIX B
Exemplary Car Functions Adaptive Cruise Control (ACC)
The purpose of the ACC is to automatically adapt the cruise speed to the current traffic and the vehicle ahead. Operability ( )
( ) ( ) ( ) ( ) ( )
Sensors and data sources
Front-Radar
Mode of Function The system measures the distance to the vehicle ahead with the radar and adapts its own speed accordingly; the driver can control the desired speed and the desired minimal distance to the vehicle ahead
Limitation Radar loses precision during rain and fog; the system is only available at velocities higher than 60km/h; the system is not designed for congestions, or extraordinary situations like accidents or construction sites
Blind Spot System (BSS) The purpose of the BSS is to inform the driver before changing lanes if there are vehicles in his blind spot ( )
( ) ( ) ( ) ( ) ( )
Sensors and data sources
Back Radar and Radar in external mirrors
Mode of Function The system identifies other vehicles in the blind spot of the car and warns the driver over signal in the mirrors
Limitation Radar loses precision during rain and fog; the system is only available at velocities higher than 60km/h; the system is not designed for congestions, or extraordinary situations like accidents or construction sites
Light Control System (LCS) The purpose of the LCS is to automatically adapt the beams to the current light, traffic and road conditions ( ) ( ) ( ) Sensors and data sources
GPS/GIS; Front Camera
Mode of Function The system adapts intensity and geometry of the beams according to external conditions identified with geo-information data or the
71
camera Limitation The system is deactivated, at daytime and clear weather
Lane Departure Warning (LDW) The purpose of the LDW is to warn the driver if his vehicle unintentionally leaves the current lane ( )
( ) ( ) ( ) ( ) ( ) ( )
Sensors and data sources
Front-Camera, front-radar
Mode of Function The system identifies lanes with the camera and the radar and warns the driver with acoustic and haptic signals if the vehicle is leaving the lane without clear intention shown by setting the blinker or distinctively steering
Limitation Radar loses precision during rain and fog; The camera becomes unreliable under bad weather conditions; the system is not designed for congestions, or extraordinary situations like accidents or construction sites
Junction Assistant System (JAS) The purpose of the JAS is to assist the driver with recognizing pedestrians while turning and maneuvering in confusing or complext junctions ( )
( ) ( ) ( ) ( )
Sensors and data sources
Front-Radar, Front-Camera
Mode of Function The system observes junctions with radar and camera to recognize obstacles and pedestrians and warns the driver with acoustic and haptic signals
Limitation Camera and radar become imprecise under bad weather or visibility conditions; the system is unsuitable for interstates because interstates do not comprise junctions, the system is not suitable for velocities above 60km/h
Night Vision System (NVS) The purpose of the NVS is to enhance the drivers view at night ( )
( ) ( ) ( ) ( ) ( )
Sensors and data sources
Near-IR camera
Mode of Function The system observes the area ahead with a night vision camera
72
and displays their images for the driver Limitation The system only works in the dark outside of cities with little
traffic, as traffic or building emit to much light for the NVS; bad weather drastically reduces the usefulness of the night vision images
Parking Assistant System (PAS) The purpose of the PAS is to assist the driver with parking ( )
( ) ( )
Sensors and data sources
Ultra-sonic distance sensors at front and back
Mode of Function The PAS analyzes a parking space with the US-sensors and steers the car in it. The driver has to accelerate the car
Limitation The system is only designed for low speed
Traffic Sign Recognition (TSR) The purpose of the TSR is to recognize traffic signs and inform the driver about their content ( ) ( )
( ) Sensors and data sources
Front camera
Mode of Function The camera observes traffic signs and informs the driver about their content
Limitation The camera becomes unreliable during bad weather and visibility conditions
Context Information Designation Type
ParkingBehavior Discrete Position Discrete Velocity Continuous Obstacle Discrete Accident Discrete ConstructionSite Discrete TrafficDensity Continuous TrafficNews Discrete RainIntensity Continuous Brightness Continuous Clarity Continuous WeatherInfo Discrete
73
Context Attributes
Scenario
Values:
( )
Required Data Sources GPS /GIS Required Context Information Position, ParkingBehavior
Restrictions
Driving Condition
Values
Stopped 0 Slow 30>=v>0 Medium 60>=v>30 Fast v>60
Required Data Sources Tachometer, GPS Required Context Information
Velocity
Restrictions
Surrounding
Values
Undisturbed Standard(
Construction Site
Accident / Obstacle
Required Data Sources TMC, Camera, Radar Required Context Information
Obstacles, ConstructionSite, Accident
74
Traffic
Values
Free Standard (
) Dense
Congestion
Required Data Sources Radar, Camera, TMC Required Context Information
Traffic Density, TrafficNews
Restrictions
Visibility
Values
Free Standard (
Dark Too Bright /DirectSun
Limited
Required Data Sources Brightness Sensor, Camera, DaylightInfo Required Context Information Brightness, Clarity
Weather
Values
Clear Standard ( )
Rain/Snow ( )
Fog
Required Data Sources Weather Channel, Camera, Rain Sensor Required Context Information
WeatherInfo, Rain Intensity, Clarity
Restrictions
75
Appendix C
Simulation Results
Table 13: Function Activity [%] depending on the Preferred Velocity
Prefered Velocity Very Slow Slow Medium Fast Very Fast
ACC 22 29 30 32 34
BSS 34 45 47 50 53
LDW 30 40 42 45 47
LCS 22 24 23 24 23
PAS 2 2 2 1 1
JAS 5 12 16 22 24
NVS 11 12 12 12 12
TSR 95 95 95 95 95
Average 2,2393 2,6252 2,7002 2,8401 2,9394
Min 0 0 0 0 0
Max 7 7 7 7 7
Table 14: Function Activity [%] depending on the Likelihood of Rain on Function Activity
Likelyhood of Rain 0% 5% 15% 30% 50%
ACC 30 30 26 22 16
BSS 52 50 42 38 26
LDW 68 68 57 50 35
LCS 12 13 37 51 66
PAS 1 1 2 1 2
JAS 36 35 31 26 20
NVS 4 4 10 13 12
TSR 92 91 88 89 90
Average 2,9894 2,9573 2,97 2,9369 2,7023
Min 0 0 0 0 0
Max 7 7 7 7 7
Table 15: Function Activity [%] depending on the Likelihood of Congestions on Function Activity
Likelyhood of Congestions
0% 5% 15% 25% 50%
ACC 32 31 27 23 15
BSS 47 47 47 47 47
LDW 71 69 61 53 34
LCS 14 14 14 14 14
PAS 1 1 1 1 1
JAS 35 35 35 35 35
NVS 5 4 3 2 1
TSR 88 88 88 88 88
Average 2,9796 2,9432 2,8167 2,6869 2,4131
76
Min 0 0 0 0 0
Max 7 7 7 7 7
Table 16: Function Activity [%] depending on the Likelihood of Accidents and Construction Sites
Likelyhood of Accidents /
Constructions Site
0% 5% 10% 15% 20%
ACC 34 28 26 22 19
BSS 49 48 47 45 43
LDW 74 66 59 51 46
LCS 15 12 13 13 13
PAS 1 1 1 2 1
JAS 36 37 37 36 35
NVS 8 5 4 2 2
TSR 95 95 95 95 95
Average 3,1539 2,9581 2,8702 2,6816 2,5905
Min 0 0 0 0 0
Max 7 7 7 7 7
Table 17: Function Activity [%] depending on the Percentage of Night Drives
Driving by Night 0% 10% 20% 30% 50%
ACC 29 28 28 28 28
BSS 45 45 45 45 45
LDW 62 61 62 62 62
LCS 0 10 20 30 44
PAS 1 1 1 1 1
JAS 38 37 37 37 36
NVS 0 5 9 15 22
TSR 95 95 95 95 95
Average 2,7197 2,8746 3,0112 3,1802 3,3746
Min 0 0 0 0 0
Max 5 7 7 7 7
![Biografie Florian Hofer [Deutsch]](https://img.pdfslide.us/doc/110x75/568c3b971a28ab0235aab3bb/biografie-florian-hofer-deutsch.jpg)
