Diagnostic Telematics and the Aftermarket
What does the aftermarket actually need in order to make this work?
by Charlie Gorman
 One of the interesting aspects of the Massachusetts "Right to Repair" (R2R) referendum, set to be balloted this November, is that it contains a requirement for automakers to provide diagnostic and repair information wirelessly. Specifically:
“Each manufacturer shall make available for purchase by owners and independent repair facilities all diagnostic repair tools incorporating the same diagnostic, repair and wireless capabilities that the manufacturer makes available to its dealers and authorized motor vehicle repair facilities. These tools shall incorporate the same functional repair capabilities that the manufacturer makes available to dealers and authorized repair facilities.” (emphsasis added) What does this mean?
I think the regulatory intent here is to make sure that if automakers use telematics technology to remotely diagnose vehicles and steer customers needing repair and/or maintenance to their authorized repair facilities, non-authorized repair facilities must have equal or similar remote access to vehicle diagnostics. Anything less would make it difficult for non-authorized repair facilities to compete, right? But the language in the referendum creates more problems than solutions. How in the world can this requirement be implemented? What exactly is being required? How can vehicle owners direct wireless communications from their vehicle to an independent repair facility of their choosing?
OEM telematic systems are closed networks that require two way communications, not one-way as suggested above. There is no direct communication between the vehicle and an authorized repair facility. OEM telematic communications take place between an OEM data center and the vehicle. The vehicle only sends raw data when requested by the data center and that data can only be in interpreted by the data center.
Maintenance and repair reports are sent from the data center to the vehicle owner and/or the authorized repair center through internet access and/or email. These communications are a product produced by the OEMs and therefore must be considered their property. This is a for profit business enterprise.
If the aftermarket wishes to compete, they must do so by developing separate systems with equal access to the vehicle by sharing the vehicle’s telematics gateway. This requires that a standard be developed that ensures vehicle security is maintained and that only authorized information is made available.
There needs to be a practical, long term solution that not only is a solution to aftermarket access to telematics based diagnostics, but is also a solution to OEMs who are attempting to sell their telematics beyond their own brand. Perhaps, in light of the Massachusetts requirement, there is enough incentive to work on an industry wide solution. There is more than one automaker that understands that a shared common solutions to remote vehicle connectivity increases the value proposition for vehicle manufacturers, service providers, content providers, and motorists.
Before a workable system can be described it is important to understand what diagnostics through telematics is and how it works. To the right is a diagram illustrating the typical OEM telematics system on today’s vehicles that feature a telematics connection to the vehicle network. This diagram describes how diagnostics through telematics works, but is applicable to any telematics function including entertainment systems, communications systems, GPS navigation systems and roadside assistance.
Definitions for terms in figure 1:
Vehicle Network - Diagnostic network utilizing OBD II and proprietary protocols
Telematics Network Gateway - This is the device that allows signals from cell phone transceiver access to the vehicle network
Vehicle Transceiver - CDMA or GSM cell phone technology. In most cases this transceiver is hardwired to the Telematics Gateway. In the case of Ford’s Sync or My Ford Touch, this will probably be accomplished by allowing customer cell phone access to the gateway using Bluetooth.
Land Transceiver - Cell phone tower provides data transfer to and from data center and vehicle transceiver
OEM Data Center - Database of customer/dealer relationships, service records, contact information, etc. Although Ford’s Sync or My Ford Touch currently does not perform diagnostics, in the future the data center might communicate through customers’ smart phones using special apps they might get from smart phone app stores.
How today’s aftermarket telematics works figure 2:
The main difference is that the aftermarket system cannot access the Telematics Network Gateway and therefore must plug into the J1962 connector normally reserved for temporary scan tool connections. This is problematic because:
- Constant connection to the J1962 connector disables OEM telematics access. It is a requirement of the spec. for this to happen.
- Only one device can be connected at a time. For example, an insurance company dongle cannot be used at the same time a diagnostic device is connected.
- Since all J1962 diagnostic connectors must be mounted under the dash and near the pedals, permanently plugging in telematics device causes wires to hang in the same area. This can be dangerous.
- Since vehicle systems were never designed to have devices permanently plugged into them, critical network functions can be interfered with and/or slowed down.
In order to create a level playing field, a specification needs to be developed that standardizes off-board communications to the OEM telematics gateway. (figure 3)
This system does not require the OEMs to do anything except standardize a Bluetooth or USB hub interface to the Telematics gateway into the vehicle network that can support multiple devices at once. OEMs do not have to provide any access to their off-board telematics infrastructure. Third parties will develop their own infrastructures.
There are OEMs that indorse a system like this. For example, BMW started an organization known as NGTP. From their website:
The NGTP Solution – Open and Adaptable Connectivity
NGTP (Next Generation Telematics Pattern) is a new approach for delivering over-the-air services to in-vehicle devices and handsets alike, with the focus on open interfaces across the entire service delivery chain.
"NGTP’s developers set the following six objectives:
- Provide a technology-neutral pattern and consistent interface and protocol for telematics services;
- Reduce barriers to collaboration and implementation;
- Enable adoption of new technologies as they come online;
- Support legacy systems for connectivity throughout the service life of a vehicle;
- Gain wide acceptance and encourage innovation through an open approach;
- Increase the value proposition for vehicle manufacturers, service providers, content providers, and motorists.
NGTP will enable vehicle manufacturers to use the best offerings from a variety of partners while maintaining a consistent driver experience. The new pattern will also allow service providers and content providers to sell the same basic services like session management or a voice/data matching to multiple vehicle manufacturers. Moreover, the NGTP architecture enables an easy integration of legacy systems, allowing older and newer vehicles alike to access new telematics offerings."
I think it is interesting, not to mention heartwarming, that their goals are similar if not the same as the aftermarket's. For more information on NGTP click here
Work is being done in ISO/TC204/WG17, Nomadic & Portable Devices for Intelligent Transport Services (ITS). It is designed to facilitate the development, promotion and standardization of the use of nomadic and portable devices to support ITS service provision and multimedia use such as passenger information, automotive information, driver advisory and warning systems, and entertainment system interfaces to ITS service providers and motor vehicle communication networks. This standard fosters the introduction of multimedia and telematics nomadic devices in the public transport and automotive world.
Intelligent Transport Services is beyond the scope of what we are trying to accomplish here, but since this effort exists, why not tap into the work they have been doing. The access to the network required for this effort is the same as what we are trying to do. Click here for more information on this effort
Another group is AUTOSAR. AUTOSAR (AUTomotive Open System ARchitecture) is an open and standardized automotive software architecture, jointly developed by automobile manufacturers, suppliers and tool developers. Again, there is no direct relationship between what they are doing and what is needed here, but many of the tools they have developed can be used in the effort.
More info on AUTOSAR can be found here.
There is also work being done by the ISO task Force responsible for diagnostic communication over Internet Protocol (DoIP) [ISO 13400]. Since they are going to use Ethernet as the transport protocol, they are going to allow more than one external connection to the vehicle at a time, similar to what was described above using either a USB hub or Bluetooth.
They have decided that specific address ranges will be used by different kinds of devices so that communication priorities can be established based on the importance of the external device and how it might affect critical network communications. Examples:
- External Legislated Diagnostics Test Equipment for emissions test scan-tool use
NOTE When using these addresses in the Routing Activation Request other ongoing diagnostic communication in the vehicle may be interrupted and other normal functionality may be impaired (e.g. return to a failsafe behavior).
- External vehicle manufacturer (dealership) / aftermarket enhanced diagnostics test equipment
NOTE When using these addresses in the Routing Activation Request and Diagnostic Messages the Routing Activation may be initially delayed (e.g. for an ECU to perform a controlled shutdown of vehicle-internal data collection) due to other ongoing diagnostic communication, which may then be interrupted and other normal functionality may also be impaired (e.g. return to a failsafe behavior)
- Internal data collection / on-board diagnostic equipment (for vehicle manufacturer use only)
NOTE These addresses should not be used by test equipment that is not designed to be integral part of the vehicle. This includes any plug-in equipment that performs diagnostic communication through the diagnostic connector.
- External prolonged data collection equipment (e.g. insurance tools, vehicle data recorders, etc.)
NOTE These addresses should be used by equipment that is installed into the vehicle and remains in the vehicle for periodic data retrieval by means of diagnostic communication. The DoIP entities may deny / delay accepting a Routing Activation Request from this type of equipment in order to complete ongoing vehicle internal communication to avoid that normal operation of the vehicle may be impaired.
In addition to the communication priorities above, diagnostic system access needs to be segregated from access to security and other network functions that might allow software hacking, vehicle theft, safety problems or emissions failures. The aftermarket is only interested in the ability to remotely communicate with vehicles in order to affect a repair. Non repair related functions on the network need to be isolated in order to avoid inadvertent or deliberate access by aftermarket diagnostic efforts.
I hope that as an industry we can begin to address telematics access issues. The need exists and it looks like it is going to be pushed along by regulation. We can wait until it is too late to do the job right and introduce a half-baked solution as we have in the past when faced with tight timelines and low resources, or we can put some resources toward it and do the job right.
--###--
|
