Reflections on NASTF meetings of Yore…
My favorite band, Rush, in their song Circumstances (Hemispheres, 1978), quoted a famous French idiom, "the more things change, the more they stay (remain) the same". As I was cleaning out some files in my home office I stumbled upon this article from the April/May 2014 issue of Tech Shop. Title: "No Longer Just a Reprogramming Standard-J2534 Discussed at Spring NASTF Meeting".
I guess I saved it because it was one of those moments my mom would be proud of me when (a) I was somehow selected to be on the panel and (b) I was quoted in the article. Perhaps this was my Andy Warhol moment? As I re-read the article, a few things lept out at me (in no particular order). Here are some odd ramblings.
The panel at the Spring NASTF meeting, held in Seattle (I believe in conjunction with the ASA training event up there), included Skip Potter, Mark Saxonberg, Brian Herron and myself. So if you do not think that things are dynamic, consider this: I now work for Brian at …; Mark Saxonberg retired from Toyota and is now a consultant and fellow board member of NASTF; Skip Potter retired and is basking in the FL sunshine and Brian Herron is now President of Opus IVS (which owns … and Autologic).
Indeed, as I read the issues we were discussing just 4 short years ago, A LOT has been accomplished. Massachusetts passed a Right-To-Repair in 2013, followed by a 49-state MOU (both can be viewed here: nastf.org/i4a/pages/inde…). Here in the summer of 2018, almost all the OEMs now have a R2R solution that uses their dealership diagnostic software with any compliant J2534-2 hardware, with the last remaining ones coming online by AAPEX/SEMA in November.
Mark made an interesting observation, that was true in his world at Toyota, about the correlation between a reflash event and relevant TSB. There are other OEMs, namely General Motors, and now Honda, that often have calibration updates and no associated TSB. As a technician, it is imperative to actually retrieve the calibration from the vehicle and compare it to the myriad of OEM databases to see what is currently loaded, determine if there are updates, and what issues those updates address.
… began a remote programming service last year called RAP (Remote Assisted Programming) , and the run rate of programming events increases on a weekly basis as technicians take the time to check. We ran some reports last week on OEM programming events, and 62% of all the flashes done by the RAP Stars (yes, that's what they are called) are GM products (Cadillac, Chevrolet, Buick, Pontiac, Saturn, GMC, Hummer, Oldsmobile). Tie that information with the fact that GM claims 70% of their ECUs do not have current software and only about 20% of the flashes have a TSB, that is cause to sit up and take notice. In my experience with GM SPS over the last 20 years (yes, we released SPS in 1997 at Vetronix) about 35% of the flash events are module replacement. Nowadays, almost every ECU on the GM LAN system has a Service Calibration and needs to be properly programmed and configured when it's replaced. That leaves 65% of the programming events are field fixes for ________(fill in software bug here). Step 6 of GM Strategy-Based-Diagnostics (SBD) is "Check for related TSBs, Recalls, PIs". This should be amended to add "Check ECU software version"
Anyhow, just though you would enjoy reading this article as much as I did, and seeing how much really has changed in just a few years in this industry. I hope you are on-board with the next round of upheaval!
Bob, I thought it was a good article the definitely highlighted some of the differences in the original expectation of the j2534 protocol compared to what it has become. My personal experience as a mobile technician is that I do a significant amount of software updates based on or other or other Factory Service information. In the brick and mortar shop environment that most are accustomed to…
Hi Bob! A blast from the past with those names. In regards to the number of modules with outdated software, do you have or do you know of stand alone software that checks module software version and verifies it is factory and whether or not there is a later version available?
Unfortunately not. GM uses a server, FCA has a pdf for non-CAN, server-based wiTECH for CAN, Ford is server-based, etc. I would like to do this as a project if we could get cooperation from the OEMs.
I bet you could, I've spoken with some of them and there isn’t major resistance. Most shops don’t update software because they don’t know how or don’t want the trouble of determining the version they have vs. the recommended version in a tsb. Many times you have to subscribe just to check the version and they simply ignore it. Personally, I do it manually on a daily basis and I have to reverse
Thank you Bob! The main reason I am asking is because more often than not when looking through service data at a particular code and gather code setting criteria, it will state, "make sure the ECM/PCM has the latest calibration." I am sure we are all familiar with this. As you mentioned, GM and Honda in particular do not always have a TSB for a specific code or calibration update. So basically I
Most OEMs have a "free" site to check calibrations. A MUST-DO with any MIL or driveability in the first 5 minutes is retrieve the current calibration(s) then look for available updates. You need to know if there are updated before you waste time chasing irrelevant diagnostic paths. The most common programming events, the Domestic brands, have 2 of 3 covered (GM and FCA) with a quick website
Appreciate the input Bob. I would have to respectfully disagree on not having an IDS as being a dumb decision. I use a Bosch Mastertech VCI and Ford FJDS and have yet had an issue with programming updates or Module replacements so far. I also have not found any other need to have it or task that I could not accomplish with an aftermarket tool. Can you perhaps elaborate on that a little?
I'm not referring to IDS specifically for programming, although over the years there have been many issues with FMP that did not appear on IDS (such as 6.0L diesel PCM failures). Nothing beats IDS for diagnostics, period. IDS not only integrates programming into the workflow, its all the other system tests that are available to save time. Examples: Power Balance, EVAP test, Fuel Injector flow
I see. just curious, when is the last time you have hooked an aftermarket scan tool to a Ford? Something such as an Autel MS908, Launch 431 PadII or even an OTC Encore or Evolve? All of the functions shown are in all 4 of those tools. Even the same power balance screen. Network sweep may be the only one that is a tad different, where the aftermarket will have an all system scan or health check…
I have used them all. Ford engineering wrote all those scripted tests in conjunction with the OEM group at Bosch/SPX/Teradyne. All the Chinese tools you listed above “borrowed” the Ford software and made it play with their cheap hardware. I prefer to use the authentic/validated version for several key reasons, including IP. Plus, ECU programming is integrated.
FYI... I was surprised to find that FJDS now does many of the diagnostic tests that we used to depend on the IDS to do.