Automotive User Interfaces and Interactive Vehicular Applications

More documents

Recommendations

Info

aspect of HMI development. For the most part, these behavior models can be developed independently from concrete graphical design. This section focuses on modeling dynamic run-time behavior while static behavior in the form of animations is considered to be created in the visual design workflow. Various techniques are available for implementing the HMIbehavior. These include manual programming in suitable programming languages as well as automatic code generation based on visual notations such as state charts or mathematical models. Seamlessly integrated toolchains need to facilitate the transfer of the developed models to the target system. Besides technical constraints toolchains also need to consider the requirements of diverse developer roles with different skills. Using UML-based state diagrams and transforming them into executable programs is a promising approach because it is relatively easy to learn and already widely known in software industry. Corresponding tools for behavior modeling that support this approach should ideally provide for both, graphical diagrams as well as textual representation of the state-machines. This is because depending on the task, both views can be beneficial. Such tools support graphical editing using UML or reduced UML dialects and textual representation based on domain specific languages (DSL). Compared to conventional programming languages, such DSLs possess a specialized vocabulary adapted to the needs of a specific domain. Due to the narrow focus they can provide a simple syntax and allow for compact specification. There are language workbenches for defining DSLs and creating a corresponding tool support including convenience features known from modern IDEs such as automatic syntax checks, autocompletion, command proposals, etc.. Such features reduce the amount of typing, help to avoid or even correct mistakes and therefore accelerate development. Furthermore, it is possible to validate the completeness, consistency and referential integrity of the models. On the other hand, the graphical notation is beneficial for simple state-machines or high level descriptions. It is also reasonable to use a reduced level of detail that hides information which is not required to perform a specific task. This allows for a comprehensive presentation of relations and dependencies between the elements. Some tools also support the dynamic and interactive presentation of the model. However, with increasing complexity and level of detail the graphical notation becomes less beneficial, and textual representation has an advantage in such cases. Another way to cope with complexity in large scale behavior models is partitioning them, as some tools support. This enables a modular design, e.g. one state-machine controls the global HMI behavior while other state-machines control single screens in more detail. Modern behavior-modeling tools support immediate simulation of the behavior model on a host environment and easy transfer of the model to the target system. To achieve this, different tools use different approaches, e.g. target-specific code generation or interpretation of the model at run-time. Seamlessly integrated toolchains need to support HMI evaluation in adequate environments as soon as the early stages. In later development phases they need to support developers to ensure controllability of the model and allow them to optimize it regarding memory consumption and performance. The complexity of the final HMI model is often underestimated in early development phases. Seamlessly integrated modeling calls for toolchains that allow successive development during all project phases as well as multiple iteration steps. 5.3 Integration of Design and Behavior: Controller-Widgets Starting from a basic HMI concept, it is possible to develop graphical presentation and run-time behavior of the HMI in parallel. During the early stages, when no basic design drafts are available, simple visual elements, such as cubes or spheres, can be used to visualize the behavior model. Later on both developmentstrains are merged as part of the global development process. Controller-Widgets are used to bridge the visual design and behavior elements and are thus available for modeling of both. They define fine-grained disjunctive functionality of only one or a few graphical elements. These graphical elements are manipulated by the Controller-Widgets’ properties or controlled by animations. While most of these properties are set in the HMI development tool at design-time some of them are controlled by the behavior model at run-time. In contrast to conventional GUI-widgets, Controller-Widgets do not come with a particular visual presentation of the widget but use elements of the design model instead. Thus, the widgets’ role with respect to the development aspects ”Design“ and ”Behavior“ is a different one (Figure 5): - Their role in the design model is to map functionality provided by the behavior model to the corresponding graphical elements and animations. Note that modification to the design might break these connections. Thus, in the HMIdevelopment tools the connections between controller widgets and graphical elements need to be modeled with certain flexibility. The connections set a search scope which is then used by the controller widget to find the actual required graphical elements. This approach allows modifying the structure of the design model without breaking existing connections. Of course, this does not apply any longer if the relevant graphical elements are removed or replaced. - The purpose of the Controller-Widget in the behavior model is the same as that of conventional widgets: They provide an interface to control the graphical presentation. The following example discusses opening and closing a door of a vehicle model. A possible implementation of a Controller-Widget offers a property to the behavior model which defines the state of the door – opened or closed. Another property of the widget is linked to an animation in the design model which defines the actual movement of the door. The widget starts this animation when the value of the property is changed at run-time. If this property is changed again before the animation ended the Controller-Widget can also adapt the animation. However, the actual basic animation is defined during graphical design process. Thus, it can be modified without changing the widget or the behavior model offering further degrees of freedom to visual designers. A different approach is required if the opening angle of the physical vehicle door shall correlate with the one of the doors of the 3D vehicle model. In this case, the widget needs to offer a property to the behavior model representing this angle with appropriate value limits. The behavior model propagates the opening angle of the real door to this property. The widget in turn modifies the opening angle of the graphical element accordingly. The separation of concerns introduced by the Controller-Widgets offer some advantages compared to conventional widgets. As the previous example shows, a different behavior of the same graphical elements in the design model can be achieved by exchanging the widgets that control them. On the other hand the design can be modified without adapting widgets.
Libraries containing multiple Controller-Widgets can serve as a modular system. These libraries need to be offered in both, the tool used for graphical HMI-development as well as the one for behavior modeling. To integrate both of these into a single toolchain, they need to share information about types and instances of Controller-Widgets. This can be achieved by enabling the behavior modeling tool to query the available widget instances from the graphical HMI-development tool. The behavior modeling tool also needs to be notified when a set of widget instances was changed. It uses this information to make their properties available for data binding. That way, design and behavior are loosely coupled in terms of functionality and development workflow. Thus, Controller-Widget libraries enable seamlessly integrated toolchains for design, behavior and the integration of these major HMI development aspects. 6. EXAMPLE: CGI-STUDIO CGI-Studio is a tool suite from Fujitsu Semiconductor Embedded Solutions Austria GmbH (FEAT) that enables the hardwareindependent development of 2D, 3D, and hybrid 2D/3D HMIs based on Controller-Widgets. CGI-Studio focuses on graphical development aspects and currently consists of the following components: - Scene Composer: a tool for authoring graphical HMIs - CGI Player: a run-time environment for HMI application development, simulation, validation on host and target environments - CGI Analyzer: a tool for design optimization regarding memory consumption and performance on target systems. More tools are currently in development and there are plans for more as well, such as a tool for translating HMI into different languages. CGI-Studio contains the 2D and 3D rendering engine Candera that is designed for automotive target platforms based on OpenGL ES 2.0. Moreover, additional components are available such as the CGI Widget Library. Graphical designs including 3D models, animations, textures, materials, fonts, images, and scene-graphs can be imported to CGI-Studio Scene Composer using FBX or other image and font formats. The imported assets can be used to model complex screens while adapting them for the rendering technology of the target. Scene Composer also supports importing and creating OpenGL shader programs and applying OpenGL ES 2.0 specific effects. Animations can be imported and modified or created from scratch. These animations can be assigned to multiple graphical elements. Iterative workflows are supported by enabling repeated Figure 5 – Workflow and Roles using Controller Widgets imports of updated designs without losing previous modification to them performed in Scene Composer. By this means Scene Composer addresses the role “Technical Artist” by providing for its common tasks. The widgets in CGI-Studio are based on the Controller-Widget concept. These widgets need to be programmed manually because on this level of detail the usage of compilable code has proven to be beneficial in the past. Of course, the widgets can also be implemented using different techniques, such as model driven development and code generation. Once a generic Controller- Widget library is available no coding is required to model the HMI. CGI Player is an out-of-the-box HMI run-time environment that can be integrated into state of the art IDEs (e.g. Microsoft Visual Studio). The aim of this tool is to support the development of CGI-Studio widgets and the HMI application layer. During the widget development the CGI Player can be launched from the IDE which enables short edit-compile-debug cycles. The widgets are built on the API of the platform-independent Candera Graphic Engine. This engine is designed for the target system but is also used in CGI Player to simulate the HMI on a host environment. Hence there is no porting effort or a need for multiple implementations of the widgets. Instead, following the concept of a single source, the same widgets can be used for both purposes. Because of tight development schedules the widgets and the graphical design are typically developed in parallel. That is why CGI-Studio supports the aforementioned mechanism to couple the Controller-Widgets to the graphical elements in a flexible way. The HMI models created in Scene Composer are exported as an “Asset-Library” which contains the scene graph and all its artifacts such as 3D models, animations, bitmaps, and fonts. It also contains the information about widget instances and their properties including their connection to graphical elements. CGI Player loads the Asset Library and renders the HMI using the Candera Engine. Because of the interpretative approach, no timeconsuming compilation steps are necessary which allows for very short iteration-cycles. CGI Player provides a customizable user interface to manipulate the widgets’ properties for testing purposes. The software of the HMI layer is the same with that which runs in the target system and the same APIs are available to control this HMI layer. The only difference is that in the target system the CGI Player’s user interface is replaced by the state machines of the behavior model.
Page 1 and 2:
AutomotiveUI2011 3rd International
Page 3 and 4:
AutomotiveUI 2011 Third Internation
Page 5 and 6:
Contents Preface 1 Welcome Note ...
Page 7 and 8:
SpeeT - A Multimodal Interaction St
Page 9 and 10:
Preface - 1 -
Page 11 and 12:
Welcome Note from the Poster/Demo C
Page 13 and 14:
Part I. Poster Abstracts - 5 -
Page 15 and 16:
The use of in vehicle data recorder
Page 17 and 18:
Information Extraction from the Wor
Page 19 and 20:
IVAT (In-Vehicle Assistive Technolo
Page 21 and 22:
ENGIN (Exploring Next Generation IN
Page 23 and 24:
The HMISL language for modeling HMI
Page 25 and 26:
Designing a Spatial Haptic Cue-base
Page 27 and 28:
Investigating the Usage of Multifun
Page 29 and 30:
Tobias Islinger Regensburg Universi
Page 31 and 32:
Gas Station Creative Probing: The F
Page 33 and 34:
A New Icon Selection Test for the A
Page 35 and 36:
The Process of Creating an IVAT Plu
Page 37 and 38:
Personas for On-Board Diagnostics -
Page 39 and 40:
On Detecting Distracted Driving Usi
Page 41 and 42:
ABSTRACT Natural and Intuitive Hand
Page 43 and 44:
ABSTRACT 3D Theremin: A Novel Appro
Page 45 and 46:
Open Car User Experience Lab: A Pra
Page 47 and 48:
Situation-adaptive driver assistanc
Page 49 and 50:
Determination of Mobility Context u
Page 51 and 52:
Addressing Road Rage: The Effect of
Page 53 and 54: ABSTRACT New Apps, New Challenges:
Page 55 and 56: The Ethnographic (U)Turn: Local Exp
Page 57 and 58: (C)archeology -- Car Turns Outs & A
Page 59 and 60: An Approach to User-Focused Develop
Page 61 and 62: Part II. Interactive Demos - 53 -
Page 63 and 64: ABSTRACT The ROADSAFE Toolkit: Rapi
Page 65 and 66: SpeeT: A Multimodal Interaction Sty
Page 67 and 68: Dialogs Are Dead, Long Live Dialogs
Page 69 and 70: Part III. Posters PDF’s - 61 -
Page 71 and 72: THE USE OF IN VEHICLE DATA RECORDER
Page 74 and 75: ENGIN (Exploring Next Generation IN
Page 76 and 77: Poster PDF missing...
Page 78 and 79: Driver distraction analysis based o
Page 80 and 81: 3. 5. German Research Center for Ar
Page 83 and 84: PERSONAS FOR ON-BOARD DIAGNOSTICS U
Page 85 and 86: Natural, Intuitive Hand Gestures -
Page 87 and 88: Poster PDF missing...
Page 89 and 90: Motivation • The mobility context
Page 91 and 92: ��
Page 93 and 94: The Ethnographic (U)Turn: Local Exp
Page 95 and 96: AutomotiveUI 2011 Third Internation
Page 97 and 98: Figure 1. All Music and filtered vi
Page 99 and 100: Using Controller Widgets in 3D-GUI
Page 101 and 102: 2.1 Modeling using Conventional GUI
Page 103: 5.1 Seamlessly Integrated Design Wo
Page 107 and 108: Skinning as a method for differenti
Page 109 and 110: 4. STATE OF INDUSTRIAL PRACTICE Spe
Page 111 and 112: In order to keep the necessary effo
Page 115 and 116: ABSTRACT Workshop “Subliminal Per
Page 117 and 118: Message from the Workshop Organizer
Page 119 and 120: For up to date workshop information
Page 121 and 122: The effects of visual-manual tasks
Page 123 and 124: 2.1.6.3 Table Task During the table
Page 125 and 126: Moreover, participants showed signi
Page 127 and 128: eferred to in speech-synthesised in
Page 129 and 130: It happens that there is a large li
Page 131 and 132: 3. SYSTEM EVALUATION We conducted a
Page 133 and 134: incorporate natural breakpoints wil
Page 135 and 136: duration [2]. Only a limited number
Page 137 and 138: situation creates CL, which is incr
Page 139 and 140: tracking is a viable way to measure
Page 141 and 142: esponsible, including differences i
Page 143 and 144: cognitive workload. The lateral pos
Page 145 and 146: Due to the fact that skin conductan
Page 147 and 148: However, all of the above mentioned
Page 149 and 150: We also wanted to know if there wer
Page 153 and 154: and more of a locked computer syste
Page 155 and 156:
using the whole windscreen as the p
Page 157 and 158:
keys to press on a visual display.
Page 159 and 160:
Interaction in the Car, in Proceedi
Page 161 and 162:
Defining explicit communication ges
Page 163:
REMOTE TACTILE FEEDBACK The spatial
Page 166 and 167:
Mobile Device Integration and Inter
Page 168 and 169:
choice. For the output of multimedi
Page 170 and 171:
AutomotiveUI 2011 Third Internation
Page 172 and 173:
The selection of any petrol station
Page 174 and 175:
visibility of available information
Page 176 and 177:
Position Paper - Integrating Mobile
Page 178 and 179:
Gartner, Smartphone sells have grow
Page 180 and 181:
Unmuting Smart Phones in Cars: gett
Page 182:
addition of new smart devices and s
show all

Automotive User Interfaces and Interactive Vehicular Applications

Create successful ePaper yourself

Delete template?

Save as template?