Contents |
Accessing vehicle network to obtain vehicle data and to control certain vehicle functionalities is the essential feature of IVI system.
We plan to make the standardized interface using D-Bus and Qt IVI package
CAN is being used widely for IVI. The diagrams above are two popular system configurations. Because of the real-time requirements about CAN communication, Configuration #1 is more preferred even though it costs more.
There're a few commercial CAN stacks. It's not only CAN chipset driver, but it also includes more functions such as filtering and parsing messages. Since each OEMs uses its own CAN messages, CAN stack is OEM-specific part and seems not easy to be standardized.
CAN Adapter communicates with CAN stack and delivers it on the specific D-Bus. It translates OEM specific messages to standardized D-Bus objects. It’s a just mapping or simple conversion, thus it’ll not be so difficult if we define D-Bus standard well-aligned with the existing OEM messages.
In the case of configuration #1, SPI or UART is used for communication between Host CPU and MICOM. In normal, OEMs use their own protocol for this communication. In the case of configuration #2, CAN Adapter and stack will be merged into one process. This approach allows OEM not to change many critical parts such as their own CAN messages or hardware configuration to adopt MeeGo. The only thing they have to do is delivering its own vehicle data on the D-Bus as standardized format.
Qt IVI is a package of libraries related to IVI. Car-System is a library to provide user application to access vehicle functionality via Qt style APIs. Although user application can access D-Bus directly, the library can help lightened the load of D-Bus coding. Furthermore, it provides convenience of Qt such as ‘signal slot mechanism’ and ‘cross-platform’.
It’s for the After-Market IVI system. In this case, IVI system can access vehicle data via OBD dongle. Usually, OBD dongle provides vehicle data via wireless such as Bluetooth. In this case, CAN Adapter should have a functionality to communicate with OBD Dongle. It may use the existing BT stack to BT communication and add functions on the BT profile level.
GENIVI plans to standardize the infrastructure to interconnect 'Host CPU' and 'MICOM' including CAN communication in the configuration #1. That either D-Bus or Qt IVI or both could be implemented on top of this infrastructure. We need to keep working closely with GENIVI to align with it.
Open platform should consider the development environment for public developers when designing its architecture. Especially, accessing vehicle network is difficult part for developers because it’s hard to test it without expensive simulation equipment. Thus, convenient simulation environment is important to encourage developers to develop various IVI Apps.
The suggested architecture can satisfy this requirement by providing CAN Adapter Emulator and Car Emulator. User can send and receive vehicle data by using Car Emulator. It doesn’t need to use real CAN type message. The purpose of SDK is to provide convenience to App Developer not CAN Adapter developer. An App developer is interested in whether his App can work as he intended or not when a certain vehicle data comes. Even so, the CAN Adapter developer can refer CAN Adapter Emulator code to make a real one.
Can Adapter Emulator and Car Emulator use TCP/IP. It can make Car Emulator work both in the same PC and in another PC without changing code. The first one is the usual App development environment for single developer. The second one using additional laptop can help to test or demonstrate an entire IVI system without connecting to the real vehicle. The third one is for developer who works on Non-Linux OS. Since Qt provides cross-platform environment, it’s also possible model on the assumption that we makes windows or Mac version of Qt IVI package.