download deliverable - AIDE

Deliverable D4.2.1 Dissemination Level PU Contract N. IST-1-507674-IP
3.2. Design scenarios and HMI meta-functions - Towards an Adaptive Integrated HMI
Presenter: Dipl.-Ing. H. Kussmann, Robert Bosch GmbH.
Today, more and more IVIS (in-vehicle information systems) and ADAS (adaptive driver
assistance systems) applications are integrated in vehicles which individually interact with the
driver and sometimes even dedicated I/O devices are used.
The main objective of AIDE is to improve the driver system interaction in terms of
preventing interference between different I/O events coming at the same time and in terms of
adapting the HMI depending on the driver state, driving situation and driver preferences. The
I/O management and system adaptation should reduce driver distraction and improve driving
safety.
In addition to that, a fully integrated in-vehicle HMI allows the exploitation of synergies
and thus, reduces HW costs and enhances system performance. Last but not least in the AIDE
project also the safe integration of nomad devices is part of the integrated HMI.
In order to reach that goal, a central component is introduced which manages the I/O
events taking into account information about the driver state, driving situation and driver
preferences. That information is summarized as "conditions" within AIDE.
It has to be mentioned that the HMI is a strong competitive factor for the car
manufacturer and there do not exist a "best" HMI strategy which can be used. Consequently,
the HMI is OEM specific.
Apart from that the amount of applications and the I/O device constellation is dependent
on the vehicle segment. Therefore flexibility with respect to different HMI strategies and
scalability in terms of system modularity are crucial requirements for the AIDE system.
For the description of the functional extent of the system, normally use cases are
implemented. For AIDE project the different interaction events and the flow of these
interactions are relevant. Within AIDE the interactions are called actions such as the output of
a route guidance information, the dial up of a telephone number or a lane departure warning.
Those actions have to be considered in different conditions. For the use case description every
action has to be combined with all other actions and those actions can be considered in all
different conditions. That would lead to an infinite amount of use cases which can not be
managed and do not lead to a suited system description.
As a consequence a generalized description approach was introduced. In a first step all
actions and conditions were categorized in groups. All actions belonging to one group are
handled in the same way from the system. The scenarios are combined groups of actions
together with a generalized solution. Solutions are the concrete system behaviour which is
used for example in case of a critical combination of parallel actions. The amount of groups
depends on the HMI strategy, i.e. to distinguish between different actions with respect to the
system behaviour it is necessary that those actions belong to different groups.
This categorization is the basis for the system behaviour description and also for the
architecture. It is crucial that those two aspects are harmonized to guarantee the flexibility to
implement different HMI strategies easily.
25/07/2005 12 ICCS