ARCHITECTURE FOR HUMAN MACHINE INTERFACES

Transcription

1 ARCHITECTURE FOR HUMAN MACHINE INTERFACES Consumers fast-changing needs demand a more holistic approach to automotive HMI development. That way Visteon developed a framework that will facilitate rapid integration and deployment of next-generation user interfaces and content in both standard and non-standard environments. The user interface cockpit UI.cockpit allows OEMs to develop graphical user interfaces (GUI) with a cockpit approach capable of integrating cloud services or CE devices easily. 28

2 AUTHORS CHRISTIAN FELTGEN is Global Director, Cockpit Electronics Visteon Innovation & Technology GmbH Kerpen (Germany). PIERRE SIGRIST is Software Manager Visteon Software Technologies Sophia-Antipolis (France). REQUIREMENTS A key challenge for OEMs is to incorporate the ecosystem consumers have on their CE devices into the vehicle. Openness, flexibility and speed are the musthave characteristics to integrate offboard features and content into these complex HMI solutions. Standardisation initiatives by automotive consortiums such as Genivi and Autosar will help in producing compliance recommendations, but they may also hinder an OEM s ability to brand its HMI and deliver functionality outside standardised platforms. While Genivi and Autosar have started standardising the platforms for the HMI ecosystem, emerging 4G access is clearly directed towards a cloud-based approach for consumers to access more powerful services, while in the car. It is no longer acceptable, feasible nor cost effective to develop a dedicated HMI solution for each component of the cockpit. Automotive HMI should be considered holistically; across components, integrating the various occupants, the role they are playing, the device(s) they are using, and the existing apps from the CE environment. The user interface cockpit UI.cockpit is a distributed HMI framework that works in a heterogeneous environment and allows OEMs to develop graphical user interfaces (GUI) with a cockpit approach capable of integrating cloud services or CE devices easily. Today, this framework is in use at Visteon in driver information and infotainment product developments and advanced innovation projects. HMI FRAMEWORK To support the transition from embedded products, ➊, to infrastructure solutions that integrate content from multiple sources, the UI.cockpit framework is based on a true model-view-controller HMI template, ➋. This framework enables development to be split into the four major HMI components: :: The controller (logic), which manipulates the model and decides which screen to display or which command to trigger, :: The model, which abstracts the service and is manipulated by the logic, :: The, which connects the model to the service wherever the location could be (on-board or in the cloud), and :: The view (graphical server), which determines what to display wherever the location of content can be (wired screen, mobile device). This framework integrates a configurable and extensible run-time engine that enables OEMs to create their own HMI ecosystem with a model-based design approach. Therefore, the OEM can focus on a HMI for all occupants in the cars rather than a specific product, component, service provider or service location. This allows OEMs to adopt a dynamic value model that can manage the entry and exit of industry participants as new content and features are introduced. Each HMI tool chain and service providers are defining their own ecosystem leading to poor usability across platform and tool chain. Each HMI tool chain and service providers are used according to a predefined ecosystem, resulting in high reusability of logic and model across platform and tool chain due to component isolation. OEMs define their models using an Extensible Markup Language (XML) description, which is based on the Simple Network Management Protocol (SNMP) Management Information Base (MIB). These models define how their HMI will deal with the needed various features (odometer, trip computer, navigation, tuner, media, voice etc.). They are used to abstract the graphical user interface (GUI) from where the feature/ service is going to be located (on-board or off-board) and the service provider that will be used. In the case of standardised features, OEMs can use the standard to define its models; where there is no standard, a generic model can be developed. In both cases the same process applies. With this model-based approach, GUIs are developed independently from any consideration of platform compliance, service provider or service location. As a result, the transition from on-board features to cloud-based content is handled smoothly. autotechreview September 2013 Volume 2 Issue 9 29

3 : Platform 1 : Tool chain 1 Project 1 Project 2 View 1 ❶ Conventional HMI development approach Controller 2 : Platform 2 : Tool chain 2 View 2 Model 2 from the service provider selection and from the location of the service itself. It enables the HMI developer to define his own data models using the SNMP concepts that are already well known in the networking domain. This key feature covers both the standard environment such as Genivi or Autosar as well as nonstandard environments, where the UI. cockpit framework allows developers to define own models. With this approach, a given service currently provided by a local software component could be modelled to allow transition to a cloud-based service without any affect on the ecosystem (without changing the models). Project 1 Project 2 ISOLATE YOUR DEVELOPMENTS : Platform 1 : Tool chain 1 UI.Cockpit View 1 ❷ HMI development approach with UI.cockpit In parallel with this principle, it is also important to isolate the HMI design and development from the various existing graphical systems to facilitate multiple tool chains. Visteon s HMI framework does not intend to replace the established graphical solutions such as Nokia Qt, HTML5 or Elektrobit EB Guide, but rather provides an architecture to separate the graphical development from the HMI logic. With this division, the UI.cockpit framework enables the development of GUIs that are easy to re-skin and allows the substitution of one graphical system for another without affecting the ecosystem. The UI.cockpit framework allows separation between the locations of the GUI logic and the graphical processing by using any kind of connection to link these two functions (local message queue, CAN, Most, Ethernet, Wi-Fi etc.). 30 : Platform 2 : Tool chain 2 UI.Cockpit UI.COCKPIT FIVE BASIC PRINCIPLES In summary, Visteon s UI.cockpit framework enables OEMs to execute a full cockpit approach to HMI development by providing the capability to build a single HMI distributed over several automotive or consumer electronic platforms. To accomplish this, the solution is based on five main and basic principles (i) abstraction, (ii) isolation, (iii) modularity, (iv) portability, and (v) distribution. ABSTRACT YOUR SERVICES View 2 The UI.cockpit model-based approach avoids the problem of a tight linkage between HMI and services. This allows the HMI to be re-usable and extensible with the possibility of being independent The model-view-controller framework enables the HMI developer to separately develop the models to be used, the logic on how to use these models, and finally, the graphical implementation that best fits the targeted platform. Specifically, the UI.cockpit framework enables a clear separation between: :: Generic model and actual implementation, :: HMI logic and graphical display in terms of tool chain and location, :: HMI and platform, service providers and network, :: Screens contents from the HMI logic and screen flow, :: Graphical connectors from network and protocol. Thus, the intrinsic separation of components provides the capability to have three parallel paths of development for the GUI as shown in ➌: :: The description of the models, the logic of HMI in managing data, screens, sources and users and the implementation of logic module for complex use cases, :: The implementation of the screens using a standard graphical environment, :: The implementation of the, linking the models to the services. MODULAR APPROACH The UI.cockpit framework provides the ability to compartmentalise the HMI

4 into various activities that can be delivered by either on board modules or modules that control external apps. For example, the media feature of the GUI can be provided by either: :: Developing a UI.cockpit plug-in that will implement the model/logic/ graphics and connect to the media engine, or by :: Developing a plug-in that controls a third-party application, which in turn manages the graphics, logic and service. This third-party application does not need to comply with the UI.cockpit architecture. With this capability, the UI.cockpit framework provides a simple way to extend an automotive HMI feature set with supplementary modules that will provide native new features or control existing third-party apps. In both cases, the feature will be integrated and piloted from the automotive HMI. This empowers the OEM to tailor the HMI in a modular way so they can easily provide incremental updates for new features instead of re-flashing the entire HMI for re-skinning, a feature update or new option. This is much more cost effective and delivers a contemporary, rich interface and experience to the vehicle occupants throughout the vehicle life. ➍ demonstrates how an HMI developed using the UI.cockpit framework can be modular and distributed over several users and platforms. DISTRIBUTION The clear industry trend is to integrate distributed processing originating inside or outside the car. The automotive HMI must therefore be designed to accommodate or facilitate partial processing by a local platform, other processing by an interconnected silver box and the final processing to be done in the cloud. This processing can be incarnated either by feature and service or by graphical rendering. With its intrinsic characteristics of extensible connectors and plug-ins, the UI.cockpit framework enables the development of HMIs that have the capability of self adaptation to various distribution scenarios. This maximises the OEMs ability to successfully manage the transition of automotive architecture from embedded products to infrastructure solutions. UI.COCKPIT FEATURES The UI.cockpit framework is comprised of a Software Development Kit (SDK) and a run-time engine. The SDK provides a set of Application Programming Interfaces (API) to extend the framework capabilities. The run-time engine develops and animates distributed HMIs. Also included is a guide for the developer that describes the architecture to be used for the HMI and explains how to integrate XML capabilities to describe the HMI in terms of: :: Users and display devices, :: Features and activities, :: Screen contents and display order/ stacking, :: Data model (data, events and commands), :: Source management, :: Screen flow, :: User rights, and :: Source management. This capability provides a descriptive approach to define the generic logic of the HMI rather than a pure programming process. The description provides the flexibility to quickly change the logic described in XML rather than the lengthy, traditional approach of changing code. Once the HMI is described using XML, the UI.cockpit framework uses this information for its run-time engine to manage the general HMI statemachine or to generate code from the XML description of the data model and screen for implementation purposes. The UI.cockpit framework integrates a set of APIs to enable SDK extensions to allow users to develop: :: Logic modules for complex algorithms that cannot be described using XML, :: Access modules for to connect PORTABILITY Visteon s UI.cockpit framework is fully portable and its general architecture enables Visteon to provide the modules that best fit the targeted platform for quick product porting and adaptation purposes. The run-time engine does not create any significant overhead burden to the system, as each event is processed in less 400 μsec among a configuration of 300 events. In addition, the modular approach requires only a small memory footprint (less than 130 KB ROM) and uses approximately 10 KB RAM. This software is already available for common operating systems such as Windows, Linux or QNX, and supports X86 or ARM-based platforms released by Visteon or by any other third-party suppliers. In-car users Displays Software Logic Data model Screen contents ❸ Parallel development paths with UI.cockpit Graphical Graphics UI.Cockpit Framework Platform Proxy Services autotechreview September 2013 Volume 2 Issue 9 31

5 User 1 User n info Custom modules Logic #1 Graphic module Logic #2 UI.Cockpit Framework DB Logic module Data model API info Graphical connector Platform services ❹ UI.cockpit-based HMI modular architecture overview your data model to the actual service, :: Graphics modules to implement screens based on the logic to be designed. The graphic modules are designed to work with multiple graphical tool chains, and :: Scheduling policy to integrate the UI.cockpit framework on the target. To help build the HMI ecosystem quickly, Visteon can also provide OEMs with the data models used for development for customisation purposes. These generic models are related to the major services, infotainment or driver information GUIs and can be mapped easily to a standard or non-standard environment. UI.COCKPIT AS THE FUTURE ARCHITECTURE The HMI is a key brand differentiator 32 for OEMs but it continues to increase in complexity and cost due to the everincreasing need to accommodate new content and features. The UI.cockpit software solution provides a holistic HMI framework to design the next generation HMI in a dynamic value model. Using Visteon s extensive experience in designing and developing premium automotive HMI, this solution supports a complex heterogeneous environment and distributed processing. New standards will always emerge to address the market needs but Visteon s solution handles both standard and non standard HMI features to provide ultimate flexibility for OEMs to differentiate their HMI. Even if the communication infrastructure may not yet be ready to offer fully comfortable off-board access, Visteon s solution allows OEMs to manage the transition effectively as the ecosystem develops and standards are defined. The UI.cockpit framework fills the gap between what the market needs and what standards define to address this need. Visteon is now offering this software solution as an option on production and advanced projects targeting Visteon hardware. Read this article on