Beyond the VIN

Vehicle-Specific “As Built” Information is Critical to Providing Complete Repairs

Contributed by Bob Chabot 

Automotive industry innovation has gradually transformed what it means to be an automotive service and repair technician. Just as vehicles have become more complex and computerized, so too has the profession of maintaining and fixing these vehicles. Once more gradual in its pace, change has accelerated in recent years to morph a trade that once was primarily mechanical into one that requires new technical, diagnostic and electronic competencies. It also requires the acquisition and continual upgrading of new skills in using modern tools, equipment and other related resources.

Figure 1. Some, but not all automakers develop and retain vehicle broadcast files for the permutations of builds a model may have. As this information has become more critical for service and repair, some automakers are now including “as built” data in various locations in a vehicle. These include glove box stickers, two-dimensional quick response (QR) barcodes, and embedding certain build data inside powertrain control modules (PCMs), and elsewhere. (All images Scott Bolt, MAHLE Test Systems)

In this brave new world of vehicle complexity, there are times that tools are the limiting factor undefined not service information, training, technician expertise or other usual suspects.

“As vehicle complexity has increased, it has become increasingly difficult for the technician to determine the exact properties of the vehicle being tested and then effect proper repairs,” said Scott Bolt, MAHLE Test Systems chief engineer, during his presentation at the Equipment and Tool Institute ToolTech 2013 event, titled Aftermarket Testing and OEM Build Information Integration.

There is no easy way today for the technician to know the full scope of properties the vehicle actually has from the VIN, but Bolt says change is on the way. Some automakers (OEMs) have long created an “as built” description file which is used in assembly plants to build the vehicle.

“Some, but not all, OEMs create, save and publish ‘as built’ files, which are also known as ‘vehicle broadcast’ or ‘build’ files,” Bolt explained. “To do this, OEMs employ their own proprietary formatting, middleware (software), hardware and infrastructure. A vehicle’s build information file is typically created by an OEM as a vehicle is scheduled and produced. OEMs also create decode protocols to retrieve these information files when needed. These files are encoded and compact undefined hence unreadable undefined and they are saved for every vehicle, for internal use.”

Figure 2. Access to vehicle data leverages rules-based relationships. Because not all data is defined, formatted and published, notably critical “as built” information, vehicle serviceability can be limited. For example, because the method of requesting build info is not yet standardized, a request for certain emissions-related data requires changes to OBDII specifications.

In the past, aftermarket vehicle testing once required only that the technician knew the year, make, model and other basic data related to the vehicle. This information was readily available from the vehicle identification number (VIN), a simple format. Many tools utilized VIN position and letter designators to enable technicians to determine what vehicle was being tested. But technicians had no way to determine vehicle options (as built data) from the VIN.

As vehicle build data and communication protocols spiraled, the information needed to effect complete service became more difficult, often impossible, for an aftermarket facility and its technicians to ascertain. Examples include certain vehicle system output controls, preconditions, run conditions, final reset functions, test menus, and configuration/setup data. However, these data relationships were complex and rule-based.

Compounding this, many OEM tool and operation strategies were not always documented. The above data relationships are rule-based and can be complex, yet without the actual build information, technicians have to resort to ‘best guess’ decisions or trying to acquire the vehicle broadcast data in other ways, which in themselves are problematic.

For example, some toolmakers and technicians developed workarounds to derive the vehicle “as built” information through PCM inquisition. This method of getting the ECU information necessary to identify vehicle content is not standard for all automakers, which in turn generates lots of complexity in the design of diagnostic scan tools.

In addition, the method of reporting vehicle content identification to the aftermarket becomes nearly impossible. Should the scan tool’s automatic mechanisms to determine vehicle content fail, service technicians questions can only be answered by visual inspection of the vehicle undefined a process that is time-consuming, impractical, inefficient and ultimately incomplete with respect to modern vehicles.

“Vehicle ‘as built’ information is becoming an increasingly necessary part of vehicle identification, diagnosis and service,” Bolt said. “Technicians today need exact vehicle-specific rather than model-specific information. Access to trim levels, infotainment packages, brake system type, and other data via a scan tool is essential to correctly connect to and service the vehicle. For example, there are instances where an OEM may change the model year for the VIN, but does not actually change the vehicle until midyear. Consequently, the VIN will not necessarily reflect the exact content of a vehicle, but a vehicle broadcast file will.”

Brand Experience Can Drive Us Towards a Common Solution

Some automakers responded to these concerns by creating vehicle “as built” information files for each vehicle that completely define every aspect of the vehicle so it can be built in the assembly plant and properly serviced in the aftermarket after purchase. This “as built” information can be created, filed and saved for every vehicle built in an assembly plant.

Figure 3. Not every automaker retains “as built” files for vehicle broadcast data; of those OEMs that do, each does it differently. For example, General Motors has more than 3,300 regular production options (RPOs). Each permutation requires its own decoding protocol. The partial decode for engine sizes is shown above.

It is well known that automakers want their customers to have a positive vehicle ownership experience whether it is a new or used vehicle. Aftermarket dealers and independents shops that service OEM customers’ vehicles want the same. Brand experience matters, it influences whether or not a customer chooses the OEM or a service facility the next time round.

With that common interest shared by industry stakeholders, rising complexity suggests that an economical and effective common solution is warranted. “There are a lot of advocates within OEMs as well as the aftermarket who want a vehicle build interface,” Bolt said. “It benefits everyone, so if the industry cooperates, rigid and onerous regulation may not be needed.”

Why Do We Need Multiple Sources and Methods of Creating “As Built” Data?

During his presentation, Bolt shared several issues pertaining to getting “as built” information, and then described how potential new standards could help automakers provide aftermarket tool manufacturers with a common method of retrieving the vehicle broadcast information through a standardized interface.

Figure 4. Bolt first presented his concept of a vehicle “as built” interface in 2012, and has since refined it to make it uniformly applicable to dealers and independents. Having the interface work in conjunction with scan tools was one of the refinements he shared in 2013.

Some of the major issues pertaining to standardizing vehicle broadcast information that Bolt shared included:

• Not all automakers create vehicle build database files.
  
• OEMs that do create “as built” databases employ different proprietary methodologies when creating, coding, decoding and requesting access to vehicle broadcast information.
  
• Those OEMs that do create build databases typically do not publish it or the interface to access it; nor are they currently required to.
  
• Standards that govern format, content, communication and other criteria are needed.
  

“Currently, OEM and aftermarket shop scan tools are surrounded by a set of support interfaces,” Bolt said. “Examples include vehicle communication interfaces (VCIs) via J2534 or J22900. “Standards are required to ensure vehicle-specific build information, can also be accessed by tool manufacturers and technicians to help them correctly identify and distinguish the actual vehicle being serviced from other possible OEM vehicle and system builds. Then they can confidently perform a complete repair.”

Five Easy Pieces

Bolt outlined five key elements required by his vision of implementing a standardized vehicle build interface:

• The sole input to the standardized build interface would be the VIN. Good design would enable technicians to ask for vehicle-specific build info using just the VIN. The VIN input would identify the user, enable scan information and facilitate PCM and other queries using OBDII mode 09.
  
• An SAE Standard that requires build information to be stored in PCMs. This would provide a standard vehicle location for build information to reside and facilitate a standard OBDII call to retrieve build information.
  
• OEM vehicle build information decodes must be published for tool integration. Given that ETI already hosts scan tool data streams, algorithms and other essential data, he suggested the organization would be a well-suited and industry-trusted choice to house this information. 
  
• An SAE standard that defines the interface to request the vehicle build information from the internet.
  
• The development of middleware server software and deployment of the associated hardware would have to be completed.
  

Figure 5. Bolt’s ideal design for a standardized vehicle build interface model would enable technicians to ask for vehicle-specific build info by communicating via a scan tool using just the VIN. Because “as built” databases will vary in length, depending on the vehicle, its systems, options and other permutations, the model would allow the interface to return to the technician a variable length message that is vehicle-specific.

In addition to a short timeframe to implement, he outlined several other advantages the model offers. “It provides a single unified mechanism of integrating vehicle build information into the aftermarket scan tools (and potentially OEM tools in the future); it utilizes existing OEM build infrastructure (for those automakers that have one); and it can be implemented without changes to the vehicle communication protocol.”

Both OEMs and the aftermarket benefit,” explained Bolt. “These include manufacturing test groups, service diagnostic scan toolmakers and technicians, service information providers, parts ordering and others.

My personal takeaway from Bolt’s presentation and ensuing discussion? I am convinced that every automaker can and should create and provide toolmakers with secured access to vehicle broadcast data via a standardized vehicle interface. It is also clear to me that the technology exists today to build a common model, based on recognized standards, that protects individual automaker interests, allows access to vehicle broadcast data by scan tool manufacturers to build more complete tools and service information, and empowers technicians to completely service and repair vehicles undefined whether at a dealer or independent facility. What do you think?