DESCRIPTION
INFRASTRUCTURE AND METHOD FOR INTEGRATING ADDITIONAL ENTITIES
INTO A VEHICLE ELECTRONICS SYSTEM
Background of the Invention
1. Field of the invention
In general, the present invention relates to the integration of consumer electronic (CE) devices into an automotive infotainment landscape. In particular, the present invention relates to an infrastructure and a method for integrating additional entities, such as CE devices and function modules, into a vehicle electronics system comprising a human machine interface (HMI) with HM control elements and at least one generic physical and logical interface.
2. Description of the Related Art
Multimedia and entertainment systems have become a significant factor inside of a vehicle. This begins with common use cases like playing songs from an MP3 player or using the in-car audio system as a hands free set and ends up with high-end in-vehicle entertainment applications with DVD player, TV receiver or gaming console for the rear passengers. Today, most of the mentioned systems cannot be simply connected to an existing vehicle electronics infrastructure.
For the most part some kind of special hardware and internal cabling is required and has to be explicitly ordered when purchasing the vehicle or needs a later retrofit installation in a garage.
Many CE devices are only able to communicate with systems especially designed for that product. A good example for this is the very popular iPod music player from Apple Computer. A lot of vendors provide cabling kits to connect and control the iPod by the existing vehicle radio control unit. To operate this specific device the radio control unit itself needs to support a matching interface and needs to be able to control the external device from a logical and user interface point of view. Less popular MP3 players are usually not supported. Even if the physical interface is matching still the logical interface, i.e. the protocol, is mostly proprietary so that the device cannot be controlled. These connectivity problems and missing support of device specific protocols can be expanded to nearly any kind of CE device. At a normal Windows or Linux PC this problem is solved by the installation of device specific drivers sometimes in combination with specific applications. This means, for each CE device interoperating with a PC or another system a dedicated driver is necessary. This device driver and eventually application is installed on the PC and every time the device is connected to it the corresponding driver is activated and "translates" the transferred data and commands into structures which are understood on both sides.
Today, this way of device integration is not practical in a vehicle for the following reasons: 1. CE devices have different physical interfaces which cannot be all supported in a vehicle just for contingency.
2. CE devices use different logical protocols and often need particular user interfaces to control them which again cannot be all supported just for contingency.
3. Existing electronic infrastructures or infotainment systems inside of vehicles are based on various hardware and software platforms. Vendors of CE devices by default provide specific drivers and applications for x86/Windows platform only. The vehicle elecfronics manufacturer cannot create the drivers for every single CE device on its own neither will the consumer electronics vendors agree to do so for a very specific platform.
4. The given vehicle electronics infrastructure or infotainment system is usually a closed system which cannot be extended dynamically, i.e. it is not an option to deploy specific device drivers and applications to this platform. Vehicle manufactures (OEM5), as a rule do not accept their vehicle electronics being infiltrated by the installation of third-party software components for security reasons.
Object of the Invention Object of the present invention is to provide a concept for integration of various entities, like CE devices and related subsystems, into a given vehicle electronics infrastructure. This concept is complying with automotive quality standards and safety aspects and allowing an easy attachment and handling of connected entities.
Brief Summary of the invention
The foregoing object is achieved by an infrastructure and a method as laid out in the independent claims. Further advantageous embodiments of the present invention are described in the subclaims and are taught in the following description.
According to the present invention the claimed infrastructure is characterized by a device integrator, which is connected to the vehicle electronics system via a generic interface provided by said system. Said device integrator provides connecting possibilities for additional entities. Tt classifies the connected entities according to their functionality into a set of generic device classes and translates the individual logical interface protocol of each connected entity according to its classification into a generic communication protocol, which is supported by the vehicle electronics system, such that a connected entity may be operated via said HM without loading any entity specific executable code into said vehicle electronics system.
Thus, the invention allows the seamless integration of a plurality of CE devices featuring various physical and logical interfaces into a given vehicle electronics system. The concept allows controlling these CE devices via existent control elements of the vehicle's human machine interface (HMI). The concrete embodiment of this HMI might be just a set of some buttons and knobs, e.g. steering-wheel control elements, or might be a sophisticated infotainment system with multiple screens and input devices.
As stated above vehicle manufactures and suppliers of vehicle electronics actually do not want their systems being infiltrated by the supplementary installation of third-party sofiware.
The invention addresses this fact by displacing the installation of device related third-party software into the system embodied by this invention. Complementary security provisions prevent malicious code from affecting the vehicle electronics system. For the OEM market the invention proposes a generic interface and protocol as a reference to be implemented by the vehicle manufacturer on its own responsibility. This implementation then allows controlling a plurality of concrete CE devices on an abstract level. Once implemented, this system-part can remain unchanged for the whole lifetime of the vehicle. Accordingly, it can be thoroughly tested and qualified with respect to automotive quality standards and safety aspects. For the aftermarket business the invention also provides a concept allowing a flexible adaptation to the vehicle electronics interfaces as-is without modification.
In a preferred embodiment of the present invention the device integrator comprises a standardized network with an integrator control unit and at least one docking connector for an interface module, said interface module enabling the inter-communication between CE devices and said integrator control unit. Said docking connector may also be used for connecting a function module providing its own business firnctionality. To facilitate the modification and especially the extension of the claimed infrastructure interface modules for CE devices as well as function modules may be physically hot pluggable units.
The concept of the present invention will be supported very well by interface modules providing not only a hardware interface for CE devices with a corresponding hardware interface driver and a corresponding hardware interface controller, but also a CE device specific software driver and CE device specific service applications for operation. Accordingly, the function modules integrating the functionality of a subsystem should therefore provide a subsystem logic driver, a corresponding subsystem logic and corresponding subsystem service applications.
In an advantageous embodiment of the present invention the integrator control unit comprises an operating system having available a diversity of device drivers for CE devices, such as Microsoft Windows. Besides, the integrator control unit comprises here an integration framework for accessing driver and application software from connected entities to verify its source and integrity as being trusted, and if so, for uploading and installing said driver and application software to enable said connected entity's specific functionality and to determine a corresponding generic device class.
The handling of connected CE devices can be supported especially well if the vehicle electronics system comprises a graphical HMI screen guiding the handling of the HMI control elements. In this case said vehicle electronics system may provide a specific screen layout for each generic device class.
Besides an infrastructure a method is claimed by the present invention using an infrastructure as described above for integrating additional entities into a vehicle electronics system. Said method is characterized in that said device integrator -accesses the specific drivers and service applications of connected entities for enabling the functionality of said connected entities; -maps the functionality of said connected entities to a set of generic device classes which are supported by said generic communication protocol; and -translates the entity specific protocols into said generic communication protocol according to the entities' classification, such that a connected entity may be operated via said HMI without loading any entity specific executable code into said vehicle electronics system.
In an advanced embodiment, said device integrator first verifies the source and integrity of a connected entity's specific drivers and service applications as being trusted, and only if so, said device integrator continues with enabling the functionality of said connected entity, otherwise said connected entity is refused.
In a preferred embodiment of the invention said generic communication protocol supports the following interactions: -Notification about attachment and detachment of an entity, i.e. a CE device or a function module, -Function calls and event notifications from the vehicle electronics infrastructure to a certain generic device, -Event notifications from a certain generic device to the vehicles electronics infrastructure.
Reasonably, upon notification about attachment and detachment of an entity the generic device class and a unique ID of said entity are transmitted to the vehicle electronics system. In some cases it may also be useful to pass a generic description of said entity's control elements to the vehicle electronics system to relate the functions of the entity's control elements to the HMT control elements. For security reasons, any kind of declarative data being uploaded to the vehicle's electronic system may be checked for conformity by a validator beforehand.
Thus, the invention provides a concept allowing the seamless incorporation of device specific control elements without considering or retroactively implementing device specific requirements on the given HMI system, especially for graphical HMIs. The invention also provides a generic approach for the bi-directional transfer of data content, e.g. music-files, image-files, video-files, but also address books from a PDA, between the CE devices and the vehicle electronics.
Brief Description of the Several Views of the Drawings The novel features of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of illustrative embodiments when read in conjunction with the accompanying drawings, wherein: Fig. 1 shows a diagram illustrating the high level architecture of an infrastructure according to the present invention; Fig. 2 shows a diagram illustrating the device integrator 20 shown in Fig. 1 with its connecting possibilities for additional entities; Fig. 3 shows a diagram illustrating the internal architecture of the device integrator unit shown in Fig. 2; Fig. 4 shows a diagram illustrating a generic communication between the vehicle electronics system 10 and the device integrator 20 as well as a specific communication between the device integrator 20 and a CE device 101 via an interface module 40; Fig. S shows a diagram illustrating the concept of using the HMI implementation of the vehicle electronics system 10 to handle CE devices connected via device integrator 20; Fig. 6 shows a diagram illustrating the advanced concept of using the graphical HMT framework of the vehicle electronics system 10 to handle CE devices connected via device integrator 30; Fig. 7 shows a Table 1 with typical physical interfaces of modern vehicles; and Fig. 8 shows a diagram of a preferred realization of the device integrator unit adapting to various physical vehicle interfaces.
Detailed Description of the Invention
The infrastructure 100 depicted in Fig. 1 comprises a vehicle electronics system 10 which provides a human machine interface (HMI) with HMI control elements, not shown and a generic physical and logical interface 11. Connected to said vehicle electronics system 10 via said generic interface 11 is a device integrator 20 which provides connecting possibilities for additional entities 101 to 105. In the example described here, a plurality of CE devices 101 to is connected to the device integrator 20 by different means. To name some of the most common connection types: USB, Bluetooth, IrDA, and RS-232. The connection might be wired or wireless; the concept remains the same. The device integrator 20 abstracts the specifics of each CE device 101 to 105 by translating the individual physical connections and logical protocols into a singular physical interface and a particular logical interface selected from a set of generic device abstractions. Hence, the device integrator 20 offers a unified generic interface to the vehicle electronics interface or available in-car infotainment system. This allows the vehicle electronics system 10 to control a plurality of CE devices 101 to 105 without knowing the specifics of a certain CE device.
As an example, a plurality of MP3 players, mobile phones, FDA's or USB memory sticks with different physical and logical interfaces might be unified by a generic device abstraction "MusicPlayer" which offers operations like getSongList and playSong to the vehicle electronics interface. The device integrator owns the knowledge about the device specific commands of a given CE device and translates the generic operations into the specific ones. Other examples are the abstraction of a plurality of mobile phones ("MobilePhone") offering operations like searchPhoneBook, dialNumber, answerCall and hookOff or using the same mobile device in the mode ("Image Viewer ") with operations like getListOjimages or showlinage. Besides a set of generic operations to control a CE device, there is usually also a set of notification events being send from the CE device to the vehicle electronics interface and vice versa. As an example a music player will post an event like playbackFinished to the vehicle electronics interface when the playback of a song or a set of songs has finished. When a new CE device is connected to the device integrator the device integrator will notify the vehicle electronics interface about this fact by posting an according event. This event contains details about the type of device which has been connected in conjunction with an individual identification to allow the vehicle electronics interface to access the CE device. Disconnecting a CE device is handled accordingly.
Fig. 2 illustrates a part of the internal architecture of the device integrator 20 shown in Fig. 1.
Said device integrator 20 comprises a standardized network 21 with an integrator control unit 30, a first docking connector 24 for an interface module 40 and a second docking connector 25 for a function module 50.
Interface module 40 extends the device integrator 20 by a new hardware interface. This is realized by physical and logical translation of a plurality of connection types, e.g. USB, IrDA, Bluetooth, RS-232, into a standardized internal network, e.g. USB or PCI. Additionally, it provides software drivers for a certain CE device 101 which will be connected to this interface module 40. The interface module 40 itself does not abstract CE device specific behaviour and functionality; it just enables the inter-communication between CE devices 101 and the integrator control unit 30. Another kind of module is the function module 50. In contrast to the interface module 40 function module 50 provides its own business functionality. Examples for function modules are GPS-receiver module or a navigation system module.
In the here described example the interface module 40 and the function module 50 are physically hot pluggable units with a standardized form factor and connector, i.e. standardized network interface 44, 54 to interact with docking connector 24 or 25, respectively. By this the device integrator 20 becomes a flexible system which can be easily extended to support new functionality and CE devices by plugging in additional modules. It should be mentioned here that, alternatively, an interface module as well as a function module might be physically integrated into the device integrator component.
A new CE device 101 to be supported by the device integrator 20 usually requires an individual software driver 45 and a device specific service application 46 for operation. Correspondingly, a new subsystem logic 53 provided by a function module 50 requires an individual subsystem logic driver 55 and a subsystem service application 56 for operation. This software package is provided by the interface module 40 or function module 50 itself. A dedicated uniform interface and protocol established between the integrator control unit 30 and the modules 40 and 50 allows the integrator control unit 30 to access, download, and install this software package without knowing any specifics about the module 40 or 50 yet. To address security issues the software package provided by a module 40 or 50 is required to be digitally signed by a trusted source.
Right before installation this signature is verified by the integrator control unit 30. In case of a negative result the corresponding module is refused. Once positively verified and installed, the integrator control unit 30 is able to exploit the functionality of the CE device 101 connected to the interface module 40 or -in case of a function module 50 -the module 50 itself. Obviously, the software package needs to be compatible to the given operating system running on the integrator control unit 30, which is described in detail in connection with Fig. 3.
An interface module 40 usually introduces a new hardware interface, i.e. device connector 41, for the connectivity to the given CE device 101. To make this hardware interface 41 available the software package includes another driver 42 to support the particular hardware interface controller 33 used by the interface module 40.
Since interface modules provide drivers and service applications for specific CE devices there is usually a 1-to-i relationship between them. Anyhow, most times the hardware of interface modules is identical for a plurality of CE devices with the same physical interface; the difference is just in the software package residing on the module.
Function modules do not just introduce new hardware interfaces but provide their own logic to realize certain services or functions. Accordingly, instead of a hardware interface controller, translating specific interfaces into the standardized network, those modules accommodate subsystems of varying complexity up to autonomous embedded computers. To integrate the functionality of such subsystems into the integrator control unit the module provides a subsystem logic driver in combination with corresponding subsystem service applications which are uploaded and installed likewise.
In the here described embodiment of the present invention the integrator control unit 30 is an embedded computer running a well-established operating system 31 like Windows or Linux. The key criterion from an economical point of view for selecting the proper operating system is the availability of device drivers for the majority of CE devices which shall be later connected to the device integrator 20. Accordingly, Microsoft Windows is the primary candidate since almost all vendors of CE devices support Windows in the first instance. Linux might be a good alternative, but here device drivers are usually developed by the community, not the vendors itself.
Accordingly, the availability and sufficient quality of a driver is more uncertain.
As illustrated in Fig. 3 the integrator control unit 30 comprises an integration framework 32 in addition to the operating system 31. The integration framework 32 verifies the digital signature of the drivers from the interface and function modules 40 and 50 and installs those to the operating system 31. As well, the digital signature of service applications is verified before uploading and incorporating them as plug-ins into the integration framework 32. Thus, the software stack of the integrator control unit 30 finally realises the translation of specific CE device and function module protocols into generic protocols as supported by the vehicle electronics interface 11.
Service applications implement the specific logic to control the corresponding CE device or function module and expose this functionality as one or several generic devices to the integration framework. The integration framework just acts as a broker between the vehicle electronics infrastructure and the specific device entities. Hence, it realises the generic communication protocol between the vehicle electronics and the device integrator. The vehicle electronics needs to implement this generic communication protocol as well.
In a prefelTed embodiment of the invention the protocol supports the following interactions, what is illustrated by Fig. 4: 1. Notification about attachment and detachment of a CE device or function module. By this event the vehicle electronics system 10 gets the information about the generic device class and an TD to uniquely address this particular entity. IDs are here assigned by the integration framework 32.
2. Function calls and event notifications from the vehicle electronics system to a certain generic device 3. Event notifications from a certain generic device to the vehicle electronics system Fig. 4 further illustrates that the integration framework 32 classifies each connected CE device and function module by enabling their specific functionality which is provided by the corresponding driver and application software. Thus, the integration framework 32 determines a generic device class for each connected CE device and function module to enable a communication between the vehicle electronics system 10 and a connected CE device or function module. Therefore, the integration framework translates device specific events and function calls into generic events and function calls according to the generic device class of the connected CE device or function module.
As explained in connection with Fig. 4, the device integrator maps specific device functionality and protocols to generic device classes. The manufacturer of vehicle electronics decides which subset of these generic device classes to be supported and implements their appliance via the given HMI of the vehicle according to individual needs. Since the behaviour of a given generic device class is well specified and fixed, the design of the HMI controlling it can be fixed, too.
For example: A specific music player is mapped to the generic device class "MusicPlayer" providing a certain set of functionality which is either supported fully or just partially by the -10 -specific player. The layout of a graphical HMT screen might be the same for all kinds of music players which will be attached to the device integrator. The only variation might be the disabling of some control elements in case that a given specific device does not support the complete set of functions of a generic device class. This strategy is illustrated by Fig. 5. Two specific CE devices A and B are mapped to two different generic device classes A and B. Both specific CE devices A and B have its representation by service application plug-ins inside of the integration framework 32. The HMI 15 of the vehicle electronics system 10 supports the control of both classes with control elements iSA of generic device class A and control elements 15B of generic device class B. The mechanism is analogous for function modules implementing a certain generic device class.
Graphical HMIs might offer advanced possibilities to support even specific features of CE devices and function modules requiring an individual representation by the graphical HMT of the vehicle. For that, manufactures basically need to equip their graphical HMIs with advanced mechanisms for dynamic extension and arrangement of graphical control elements. Additionally, the graphical HMT needs to implement an extended protocol for the interaction with the device integrator.
The concrete design of this protocol is influenced by the following factors: 1. Required flexibility 2. Security constrains 3. Bandwidth and latency of the connection between the device integrator unit and the vehicle electronics 4. Available hardware resource reserves Depending on the concrete embodiment of the protocol the overall complexity and scope of the supporting software architecture varies and splits into different portions on the part of the vehicle electronics and the device integrator unit.
The following approach allows interface and function modules to provide a generic description of its individual control elements. The generic description might be an XML file but can be of any other format either. The integration framework of the device integrator control unit forwards this description from the module to the vehicle electronics in the context of the device attachment notification procedure. The description does not contain any information about the style of control elements but only the type and optionally the arrangement of the elements.
Hence, a module is not able to provide its individual look&feel, this is subject to the graphical HM itself The set of available control element types is pre-defined and depends on what is in fact supported by the HM framework of the vehicle electronics, for example push buttons, radio buttons, sliders, edit fields or list boxes. The graphical HMI framework is free to decide how to incorporate the specific set of control elements into the existing user interface. As an example, the framework might create a separate screen page for every module demanding individual control. The individual control elements will be placed on this screen page according to the generic description provided by the module. The framework additionally places an additional control element at distinct positions within the menu hierarchy of the HM to access this page.
The system might support multiple pages per module.
Thus, the invention provides a concept for graphical HMIs allowing the seamless incorporation of device specific control elements without considering or retroactively implementing device specific requirements on the given HMI system. The invention also provides a generic approach for the bi-directional transfer of data content between the consumer electronics devices and the vehicle electronics, e.g. music-files, image-files, video-files, but also address books from a PDA.
The actual business logic is implemented and executed either on the CE device, a function module, or the device integrator control unit. Fig. 6 demonstrates the concept exemplarily by means of an interface module with a CE device connected. Speaking in terms of the well-known architecture pattern MVC (Model-View-Controller) the vehicle electronics represents controller and view, the model is represented by one of the functional entities stated above.
On interaction of the user with a control element by some means as clicking, touching, etc., the graphical HMI framework posts an according event notifying the associated device about the status change of this control element. This notification usually triggers a certain operation at this device which in turn might change its own status. This status change will be notified back to the graphical HMT framework allowing it to update its graphical representation. A device might also post status update notifications on a frequently basis in case that the status changes arbitrary, e.g. elapsed time of a played music track. Several variations and alternatives to the classical MVC pattern exist which could be used here as well.
The infrastructure and corresponding method described here foresee a multistage security concept to protect the vehicle electronics from being harmed by malicious third-party code: 1. Only digitally signed software packages proved to originate from a trusted source and being intact are going to be installed to the device integrator by the integration framework of the integrator control unit.
2. Trusted third-party code is exclusively deployed to the device integrator. No executable code is going to be uploaded to the vehicle electronics, but exclusively declarative data like generic descriptions of HMI control elements.
-12 - 3. Any kind of declarative data being uploaded to the vehicle electronics is checked for conformity by a validator beforehand, e.g. by XML Schema Validator.
4. For the case of an OEM integration the obligatoiy connection to a vehicle diagnostics bus, e.g. CAN, is completely separated from the device integrator control unit by a firewall. No physical communication channel allows the software components installed on the integrator control unit writing to the vehicle bus. The software of the integrator control unit is exclusively able to send periodical heartbeat messages to the hardware control unit to indicate its proper operation. This indication is realized by a simple GPIO pin toggle which can't be exploited by any means.
In an advantageous embodiment of the invention the standardized network is based on USB (Universal Serial Bus). This interface category is widely spread and can be considered as today's de facto standard for interfacing external peripherals to a Personal Computer. The market offers a huge variety of off-the-shelf adapters allowing retrofitting other categories of interfaces via USB. Examples are Bluetooth-to-USB dongles, hDA-to-USB dongles, and RS-232-to-USB dongles. Software drivers required to operate these adapters are usually provided by the vendor for the Windows platform so in case of the integrator control unit is running on Windows those software drivers can be used out of the box. In case of Linux the situation is similar but the drivers are usually not provided by the adapter vendors but rather by the Linux community.
Finally several factors will influence the selection process regarding a suitable operating system to run on the integrator control unit.
Another benefit from choosing USB for the standardized network is the fact that a lot of CE devices come along with an USB interface innately so that the required interface module is actually just a mechanical loop through. The only additional content of such a module is the flash memory providing the software package for the specific CE device. Even this device specific package can be omifted if the CE device conforms to one or multiple of the generic USB device classes, e.g. mass storage. For those generic classes the drivers are usually innately provided by the operating system, e.g. Windows and Linux. As long as the connected CE device relies on these generic device classes no dedicated driver needs to be installed.
Finally, USB allows a simple way to provide software packages residing on a module to the Integrator control unit. Each module providing software drivers will implement a mass storage device. As soon as the module is plugged into the system this mass storage device is detected and activated by the integrator control unit allowing it to access the software packages with standard file system mechanisms.
The concept described so far assumes the vehicle manufacturer is implementing the proposed generic interface to the device integrator unit. Even if this is the favourable approach for the -13 -OEM market to obtain most seamless integration this might either not be supported by a given vehicle manufacturer or is not an option in case of the invention shall be retrofitted into a given vehicle infrastructure. In those cases the device integrator unit needs to accommodate to the given physical interfaces and logical protocols of the vehicle electronics.
Table 1 of Fig. 7 lists typical physical interfaces of modern vehicles.
The following approach, illustrated in Fig. 8, allows the device integrator unit 80 adapting to various physical vehicle interfaces 70 based on a single hardware platform. The flexible adaptation is basically achieved by a here called "Chameleon" FPGA (Field-Programmable Gate Array) 82 translating the protocols between various concrete given vehicle electronic interfaces and the actual device integrator CPU 81, which is running the software stack as described before. The physical adaptation is achieved by a set of transceivers (PHY) 83. For standard and cheap vehicle interfaces like CAN, UN, etc. the according transceivers are on-board on default.
More expensive and at the same time less usual interfaces, predominantly wireless interfaces like an FM-transmitter 84 or Bluetooth, can be retrofitted as plug-in modules. The interface controllers actually needed for a specific physical vehicle interface 70 are realised by programming the Chameleon FPGA 82 accordingly. An additional software unit running on the Device Integrator CPU 81 completes the adaptation by converting vehicle specific commands, e.g. originating from a radio unit, into generic commands and vice versa. Thus, the invention provides an additional concept for the aftermarket business allowing a flexible adaptation to the vehicle electronics interfaces as-is without modification.