download deliverable - AIDE

Deliverable D4.2.1 Dissemination Level PU Contract N. IST-1-507674-IP
I/O Devices
(real)
ICA
inform
direct
access
Application
Figure 5: I/O device access for warnings
It was pointed out that this approach might be problematic when different warnings
should be combined. The presentation of two concurrent warning is a quite new research area
and several problems have to be solved, e.g. timing, derive an appropriate joined warning, etc.
It was also remarked that in the future a warning might not address a dedicated I/O device.
3.10.7. AMI-C HMI approach
The AMI-C HMI architecture approach was introduced by Mr. Scott Andrews via
phone conference.
This approach is based on the following situation and resulting requirements:
• Addition of new functionality to the car implies additional HMIs
– Every device or software application will need to interact in some way with the
driver/occupants.
• The car makers need to control HMI
– “look and feel” for the mark,
– safety and liability.
• We can’t allow arbitrary applications, devices or services to impose their own HMIs in
the car.
Therefore the AMI-C approach strictly separates the HMI from the application
functionality. This is illustrated in
Figure 6. The application interacts with a HMI manager which is similar to the ICA
component in the AIDE architecture.
The HMI manager implements the interfaces to the visual, tactile and audio HMI systems
available in a car and it implements the HMI policies and priorities for the car maker. For this
purpose XML based interfaces between application and HMI Manager were defined to have a
common way of referencing HMI needs (outbound from application) and HMI results
(inbound from car/user).
Thus the HMI Manager renders the output according to the OEM HMI strategy.
25/07/2005 38 ICCS