Can the cloud play an important role in the detection and correction of quality and service issues from the instant a car leaves the assembly line and thereafter?
The onboard telematics systems, which are tied into the data buses that monitor and control all key systems on a car, may have more than just a cell phone chip to call a help center for road service. They also may include a modem through which the vehicle communicates with cloud servers.
In addition to infotainment and navigation, telematics already has been providing opportunities for monitoring the condition of a vehicle. But it’s been limited to just a few after-sale service functions, such as General Motors' OnStar with unlocking a car, slowing a stolen vehicle, and issuing vehicle “health reports” and basic trouble code descriptions. Now, other car makers are looking at a wider range of opportunities, although some pose challenges that first must be overcome—and not all are technical.
Hyundai may be the first company to use the telematics modem in its Blue Link system to begin the monitoring process from the instant the car comes off the assembly line and continue it until a customer has taken delivery. And even from that point, if the customer approves, there is the call center report on trouble codes, even a related data transmission to a cloud server for analysis, plus the stolen car slowdown for police pursuit.
The Hyundai system already has yielded results, and the company does see a number of appealing ways to move ahead, explained Erwin Raphael, Director of Product Quality and Service Engineering.
Customer privacy is an issue, and Nissan’s original attempts to monitor the Leaf in operation led to public objections that resulted in deactivation of the extensive vehicle monitoring system. So today, only if a Leaf customer signs an okay, will operational data even be collected, and then it goes only into an aggregating server to spot service issue trends, but without specific vehicle ID. However, Hyundai also has a server with aggregating software but saw some additional opportunities. It has identified where it wants to go in its next-generation system and is working to get around some present limits.

Early warning provided

When a car comes off a Hyundai assembly line, the modem is on, so if a failure has occurred that was not identified in the end-of-line (EOL) diagnostic check, or was triggered during transportation of the vehicle or while it’s in the dealer lot, the notice goes into Hyundai’s aggregating cloud server. This is one of the early-warning systems that Hyundai has put in place to further improve quality, explained Raphael.
As an example, the tire pressure monitoring system on the new Santa Fe was being set for too high a sensitivity, so each car coming off the line would trigger trouble codes for the pressures in all four tires. Although the information went through the aggregating cloud server, the trouble codes tied to a specific car line meant Hyundai was able to realize that something was wrong at the assembly plant and quickly execute a fix.
All new cars go through a Pre-Delivery Inspection (PDI) at the car dealer, but the cloud system also offers the opportunity to perform an electronic PDI (E-PDI), and that is in Hyundai’s plans.
The limitation of the currently possible data collection and transmission system, which is based on OBD II (on-board diagnostics), is that it requires a diagnostic trouble code to generate a message from the modem to the cloud server. However, many codes are accompanied by a “freeze frame” display of sensor readings, called PIDs (Parameter IDs), which can be helpful.
For increased effectiveness, vehicles would have to be started and running for some of the E-PDI tests. That’s feasible because start-and-run often follows E-O-L, driving vehicles on and off the trailers that deliver car to dealers, and for in-dealer operations. Inasmuch as a car still is owned by the vehicle manufacturer prior to delivery, privacy factors have not yet come into the picture. Assuming a dealer did not object, the monitoring could continue until the vehicle was sold, so demonstrators also could be covered, providing another source of vehicle quality information.
At the beginning, a cloud-based E-PDI would probably be used to alert dealers to any issues detected, but as it becomes more robust, it could supplant that aspect of the pre-delivery process.
One useful post-delivery service opportunity would appear to be continuous monitoring of a vehicle with an intermittent problem. It can be done, but to be really useful would require continuous sensor data transmission, rather than just a trouble code and a single “freeze frame” of sensor data. There already are available “flight recorders” easily installed to provide continuous monitoring and record data, so this feature is lower priority.

Reflashing issues 

One seemingly sure opportunity for the cloud connection would be for software updates—reflashing vehicle computers to the latest level of software, particularly to correct driveability and safety issues where possible. It’s probably on every carmaker’s “wish list” because it could save money and ensure critical updates are made promptly.
However, Raphael pointed out, this is the toughest challenge, even if the legal concerns were overcome with releases and remote identification of a viable setting (such as engine warmed up, vehicle parked, etc.). Here the challenges raise both technical and denial-of-use issues, he said, including sizes of the files. Some reflashes are so long that an owner might have to dedicate hours, and although that’s possible with a personal computer, a motorist might become impatient.
Just for openers, the modem and cloud server would have to identify the software level in the car, a shop procedure typically performed with a factory scan tool. Also, reflashing typically requires specified, stabilized voltage to a minimum level, and if the voltage dropped, the reflash likely would fail.
It is possible for a smart charging system to provide that capability and even transmit the voltage data to the cloud server. But to maintain the voltage through an entire reflash, the file size would have to be very small. So some reflashes still would have to go to the car dealer, even if not all.
The system would have to be designed for recovery in cases where a file didn’t load properly or if the motorist had to abort it for a driving emergency. And even if it seemed to go well, there would have to be an absolutely positive verification algorithm, Raphael pointed out. “The current system does not perform reflashes and is not designed to,” he noted.
Here again, the first applications of remote reflashing would likely be done when a car is in the dealer shop for other service. During this period, one of the special battery chargers used to maintain required voltage for reflashing could be connected, and the success of the update could easily be verified. However, verification often is done by a shop scan tool, so a cloud-to-modem equivalent is well within current technology.