Vehicle Module Architecture

Modern vehicles are increasingly becoming supercomputers on wheels. The ability to inject and extract data to and from the vehicle will open up huge opportunities in terms of safety, efficiency and the development of new services.

Work package 4 focuses on extracting information from vehicles by studying and using the most suitable technologies. In addition, further studies are conducted in the areas of technology analysis and vehicle centered use-case development.

This work package considers available and emerging communications technologies and maps them to use cases identified in work package 2. Further, the work package makes contributions to other project areas leveraging the team's expertise on networking modules & core platforms.

The main objectives of work package 4 are -

• Vehicle Technology Analysis - Analysis of techniques and technologies currently used in the automotive industry for the implementation of in-vehicle networks
• To create an hybrid HW/SW system capable of accessing information from within in-vehicle networks
• Input to system requirements and specification for use cases prioritised by work package 2
• Vendor Survey and Cost Analysis
• Use Case Development - study and create a practical vehicle centric use case

Vehicles today have complex subsystems, each of which is responsible for ensuring the proper functioning intended as a vehicle is used for transportation, or for improving some cross-functionalities, like a vehicle's active and passive safety mechanisms, passenger comfort, and trip quality.

Project Vehicle - Honda HR-V

Usually, each function is carried out by a specific vehicle subsystem, that is composed of one or more Electronic Control Units (ECUs), and a set of sensors and actuators. Each vehicle subsystem has specific requirements which makes it necessary to use appropriate technology depending on the subsystem's requirement. As vehicle functionality grows, the number of vehicle ECUs increases. Currently, that number is estimated to be greater than 70 for a standard vehicle. Moreover, most of the ECUs also need information from other subsystems in order to complete their tasks (e.g. with more than 2500 signals exchanged on the whole). It is therefore necessary using the right communication network to interconnect the in-vehicle subsystems, in order to guarantee proper communication between them, and at the same time, reduce wiring needs.

Vehicle Bus Technologies

These subsystems can be connected via a number of vehicle network technologies and protocols, each of which was developed with different goals in mind. These include CAN, LIN, MOST, FlexRay and more recently Ethernet.

It is also important to understand that different in-vehicle network topologies are used today. The most common is the Central-Gateway topology where the vehicle is comprised of 2 or 3 'domains' or alternatively the Backbone topology where the vehicle has a greater number of domains. Small to mid-sized vehicles generally use the former with luxury cars using the latter.

The project team had the opportunity to investigate these state-of-the-art technologies with respect to in-vehicle networks and how therefore to access the desired information from within the vehicle.

Given that In many cases, the vehicle is equipped with a Central Gateway and CAN bus as a Backbone in order to allow the interaction between different components, access to the CAN bus is the most practical way for the purposes of after-market development and testing. This access may be attained via the OBD (On-Board Diagnostic) connector. Note that not all data may be accessed via the CAN Bus and as such would require a gateway function linking into multiple vehicle networks.

The project team has developed a system component for extracting data from the in-vehicle network, which is integrated with the Epitomical On-Board-Unit. The component uses a CAN Module and a CAN Transceiver for hardware interfacing, and Socket CAN for the implementation of data gathering algorithms.

In-Vehicle Data Extractor Prototype

The system component employs the CAN-based ISO 16765 diagnostic protocol for data extraction and the OBD-II data-link connector for interacting with the in-vehicle network. The proposed data gathering approach is OBD-II compliant based ISO 15765 which is used by almost all vehicle manufacturers as a standard diagnostic protocol. Possible future changes to the terms of use of the OBD-II suite, in the way vehicle diagnostics is managed, or even in the in-vehicle network structure, could change the baseline scenario.

As part of the use case development work for work package 4 the team has documented an approach based exclusively on data obtained from the in-vehicle network for the analysis and the control of vehicle emissions.

In addition, as in work package 3, a vendor survey and cost analysis was undertaken to identify and quantify the required components to build both a factory installed and after market solution for vehicle data extraction.