ISSUE RESOLUTION LOG

Date	Name	Issue	Date	Name	Resolution
		Page 1; no indication to turn ign key to run.  Prompt inspector to remove key from ignition, then wait 30s, then install key into ignition, then turn key to KOEO and watch MIL.			Added "insert key and…"
		Page 1; page connector should be A, not C.			connector says "A"
		Page 3; Total_PID_Count should be capped at $20.  There are some Toyota's that will respond with data at $60, $80, etc.  And there needs to be clear instruction on to add the total number of supported PIDs...i.e. do you simply add the contents of PID $00 and $20?  Or do you add the contents of $00 and $20 and PID $00 and $20 themselves?			Not necessary to cap at $20.  Using values above $20 provides improved separation of models.  Doesn’t matter if PIDs supported are defined by SAE or not for the purposes of totaling the number of supported PIDs.  Command has been attempted to be clarified to increment counter by one for each bit set to 1 in the PID $00 response message including the bit that indicates support for PID $20.  If PID$20 is supported, continue incrementing with PID $20 response message and so forth.
		Page 3;  If ARB and EPA are not going to keep track of this, then who will?  Or is it a thing that as you compile data the answers will lie in the data?  Keep in mind that the contractor will have to create something that can go look up the same vehicle, or a certain number of same vehicles, and then determine the expected count.  How long will this take?  Will it be acceptable for the user?			I have mixed feelings about how useful this can be to accurately catch "clean screen"/fraud.  I prefer not to take on this task (and EPA also does not want to) because it may be of very limited value.
		Page 3; the whole comm establishment deal with an incorrect module does not seem to be too clear.  I think that I know the message but I am not certain that others will get it.  Are you certain that the condition outlined in the decision box (lower left) is a documented and repeatable condition?			Yes, this is a vehicle that truly exists.  A non-OBD module wakes up to KWP initialization but doesn't support any PIDs.  The actual OBD II ECUs use ISO-9141 protocol
		Page 3; text box, lower right.  How do you intend to establish comm using a certain protocol?  A GST does not have to know which protocol to initiate.			Sorry, a known vehicle problem that exists, was not recalled, and needs to be worked around.
		Page 4; text box titled "Option to State to handle vehicle".  Who is going to define the special case handling?  Each State?  How does the State know the special handling conditions?  Oh man...			EPA will likely make recommendations.  States may or may not follow them.  Sorry.
		Page 4; junk the special note/question.  It should not be required as communication is established at this time.  Does ARB have a requirement that a GST should not loose communication when transitioning from KOEO to KOER?			Yes, it should be required because it is necessary to avoid reading a MIL command status of "ON" during a bulb check.  It is imperative the technician has the engine running to avoid this stupid false fail condition.  My guess is many times vehicles do hiccup and lose communication so I am going to boot the user all the way back to the beginning.
		Page 5; text box, lower center.  A specific tool manufacturer is called out.  Recommend the use of "OBD" instead of existing term (this chart is generic in nature).			State I/M people are worried specifically about the EASE simulator so I wanted to appease their worries and show that the system is capable of detecting it.
		Page 7; add text "PID$01 and" to "Do any ECUs support Mode $09, PID$02 (VIN)?" decision box, so it reads as "Do any ECUs support Mode $09, PID$01and PID$02 (VIN)?".  Add this to the 2 I/O boxes below it.			Done.
		Page 7; where does the manual VIN input confirmation occur?			Manual VIN input as well as make model year license plate, etc. is all assumed to have been done long before entering the I/M OBD flow chart.
		Page 8; add text "PID$03 and" to "Do any ECUs support Mode $09, PID$04 (CAL ID)?" decision box, so it reads as "Do any ECUs support Mode $09, PID$03 and PID$04 (VIN)?".  Add this to the 2 I/O boxes below it.			Done.
		Page 8; who will provide the CAL ID/CVN lookup table?			TBD.  Probably joint state/govt/OEM/contractor
		Page 8; add text "PID$05 and" to "Do any ECUs support Mode $09, PID$06 (CVN)?" decision box, so it reads as "Do any ECUs support Mode $09, PID$05 and PID$06 (CVN)?".  Add this to the 2 I/O boxes below it.			Done.
		Page 8; who will provide the CAL ID/CVN lookup table?			TBD.  Probably joint state/govt/OEM/contractor
		. Page 10; didn't the system already collect data and supply Number_of_Stored_DTC_Counter?  Why again? The consumer part of me says that now the vehicle is being tested twice. The test checked it earlier, and yes the system could have set another DTC			SAE J1979 specification dictates this.  If DTC has set between request for number of DTCs stored and request for actual DTCs, the numbers may not agree and you restart the process.  If you recall, you only enter the loop to read DTCs if the MIL is on so there is no chance that a consumer would have "passed" up to this point, then a fault code sets, and then he gets failed because the fault code sets during the inspection.
		Page 11; will the vertical path going from the text box "set flag to: MIL_KOER_Visual_Result=Pass" to the off page connector result in an endless loop?  This is common in flowcharts like this and I am surprised that we have not created one yet!  Please check this operation.			I haven't identified an endless loop yet but wouldn't be surprised to find one.  Let me know if anybody identifies one.
		Page 11; input and decision box on left middle.  Why are we asking the operator to do another visual MIL check?  Seems that this should be handled with page 1 flow.			Oregon data would suggest high incidence of incorrect decisions made by technician where MIL command is off but bulb check or KOER check is failed.  This should be an extremely extremely extremely rare case of a burnt out bulb or serial communication failure.  I didn't think the extra hassle for the very very very few vehicles that truly fail compared with the hassle of mistakenly failing even a couple cars due to technician error.
		Page 11; text box on left side, top, titled "Vehicle Failed OBD Test". There is no "3)".  Why?  Also why is the Readiness_Test_Result=Pass/Fail? Shouldn't it be "Fail" only?  Or is it being failed based on the data contained in "6)"?			Misnumbering.  Corrected.  At this point, readiness status could be pass or fail--electronic info has failed the car and readiness status could be either.
		Page 1; special note, change "every" to "ever"			Done.
		Page 2; does "communication success" need to be further clarified?			Probably.  Any suggestions???
		Page 3; does the decision block "did only one ECU respond and did it have a module ID in the range of $18-$1F" account for Chrysler's node address $41 transmission)?  If the goal is to trap only the transmission ECU responding and send program command to again poll for OBD II ECU's this may not get it.			I have put two "traps" into the test sequence to try and catch cases where only the TCM module is communicating.  However, these traps do not fail the car--they just make the equipment retry Mode$01, PID$00 requests to see if they get "lucky" and get a hit on multiple modules on a retry.  Hopefully, all these problems are resolved by tool manufacturers but I have seem some scan tools hit and miss on the multiple modules and something as easy as re-initializing can be successful.  Would this be better done by restarting the initialization process (e.g., wake-up sequences) rather than retrying PID$00?
		Page 6; where is the label Number_of_Stored_DTC_Counter set to 0?			Fixed.
		Page 7; you are expecting a response for the M$09 P$00.  Not all ECUs send a respond to a M$09 message, so something needs to make mention of the fact that no response means not supported.			Fixed.
		Page 7; will more than one OBD II ECU come back with M$09 VIN support? If so, what should be done in that case?			Not allowed to for 2005 and subsequent model year.  Prior to 2005, VIN not required so some manufacturers may have complied and may have done it incorrectly.  Suggestions??
		Page 7; if the PCM has been replaced and the VIN has not been programmed in to its memory, what happens?			Car fails.  Must return to repair facility for VIN installation.
		Page 8; same thing about the expected response for the M$09 P$00 (CVN and SI).  Not all ECUs send a respond to a M$09 message, so something needs to make mention of the fact that no response means not supported.			Fixed.
		1. page 1 In the visual MIL check,  the KOER portion should be done after the scan, that way the appropriate time has elapsed,  when the scan is completed the software should ask whether the light is on.  That way there is not 10 seconds of down time.  So move that block to the end of all scanner interaction with the vehicle.			Good point.  I have moved it to after Mode $01 and Mode $09 data collection but left it prior to Mode $03 data (DTCs) because DTCs are only pulled if the car fails one of the MIL checks so I wanted all three MIL checks performed before deciding to check for DTCs.
		page 2  In the scanner software, some manufacturers have retries built in for the communications, this is good.  But once communications are not established, ask the tech to check everything and try again.  He will be angry and will not check anything more than just the initial check if communications is failed.  I believe what to do is to give him the option to retry,  so  I think that you go through the initilize comm.  if no success prompt to check, and ask if the tech wants to retry,  if he does he can circle that loop as much as he wants to, but he is not forced to go through it three times on a real failure.			I originally wrote this assuming all protocols would be tried once, then the loop of three would begun.  In the end, I don't care if the retries are within the tool or within the I/M integrated equipment (the flow chart does not distinguish between what has to happen in one versus the other) as long as each protocol is tried multiple times by the tool and the tech is given a prompt to make sure it is firmly connected and the engine is running.
		page 3 First, an editorial,  I don't believe any spec requires the exact same amount of pids to be supported on like model vehicles.  This is a false argument to fight clean scanning and should not be used, and should not be specified,  but if it going to be specified,  it must be consistent with all scan tool mfgs.   One suggested formula is  pid count = number of bits set to 1 in pids $00, $20, $40, $60 Once again,  I believe even if there was a large collection of data, it would still be an invalid test and my vote is to eliminate it completely, because you never know how many different controllers are matched with each other and what they all support even among like vehicles, so the first to get tested passes and then someone down the line fails because they were tested at a later date.			I agree.  PID count has limited usability in my opinion but some states are insistent in pursuing it even if it can only be used for gross distinctions (Chryslers vs. non-Chryslers, etc.).  I have tried to clarify how to count the PIDs but your language may be better.  If others believes it is clearer, I will use it.
		page 3 The Hyundai problem as we know it is not waking up with the wrong protocol. On the Hyundai vehicles that we had a problem with the behavior was as follows  nothing wakes up to 9141  we always check that first  two ecu's wake up to kw2k  engine and transmission,   they engine was a siemens controller and the transmission was a keifco  they both continually respond to mode$01 pid $00   This can go on for hundreds of messages in a ping mode.  the scanner asks for a mode$01 pid $01 and 40 to 50% of the time, the engine ECU shuts down and the transmission ECU continues Since the engine ecu does not answer the m1p1 when you look at readiness tests, the only ecu that has answered is the transmission and it has no readiness tests complete, although from the best of my recollection, it did support two pids.  Since the transmission ecu does not support many things when you begin to ask for pids that were supported by the engine, there is no response. In the event of no response, the scan tool should attempt another m1p0.  If there is no response to that, communication has failed.   On the Hyundai, the engine computer never comes back and answers after it fails on the m1p1 until it is reset by performing another 5 baud kw2k slow wake up sequence. It is our belief that this is caused by one of the Hyundai ecus not arbitrating the bus correctly and after a violation of the timing, shuts down the 9141 link and needs to be restarted with the 5 baud.  So, if this is the case and you have the $18 answering and it supports (if I remember right) RPM and vehicle speed, then it will pass this test but fail the OBD-II			This is a separate Hyundai problem.  How would I work in something into the flow chart that addresses this problem?  Something more that helps identify when one or more modules that used to be responding are no longer responding?  How would I work that and where would it go?
		page 4 special note/question   I would say send them back to the beginning, because if it is a 9141 link there is a chance that it is reset and will not answer again to the pids,  then the scan tool should recover but some manufacturers may just fail the comms instead of retrying a 5 baud sequence.			I agree and have directed them to re-initialize.
		page 5 For I/M inspections,  I sure like the oringinal  complete/not complete It is certainly more descriptive of what is happening, because there is a software module that is either not completing, or completing,   The readiness status is a compliation of whether or not the monitors (which are software modules on the vehicle) have completed or not.			I also prefer the complete/not complete descriptions but Arvon on others insisted on ready/not ready.  ISO/SAE comprimised on the yes/no in response to "cat_rdy", etc.  It does also provide some better distinction between the new PID $41 where some similar terminology is used with completely different meaning.
		page 5 Is the EASE box a standard at this point,  it seems that if there are conditions which are invalid are to be flagged, let's flag the conditions, If it is truly impossible to have A/C system refrigerant monitor supported but not complete (and I don't recall seeing it in the spec) then flag the condition.  There are also others,  for instance, pid $1D and pid $13 will never be supported at the same time (definately in the spec and  another way to catch the EASE simulator) then we should define all of this criteria. But only if it is real criteria, not soley to catch one simulator in the market.   If someone wants to make a simulator to fool the system, it is not that hard.			Yes, the EASE is box is standardized in that the device ID is locked at $FD and the AC refrigerant monitor is locked at supported and not ready.  Yes, it is true that no real car exists where AC refrigerant is supported.  See note above but specific I/M state people were directly concerned with the known publically available EASE product so I mentioned it by name to draw their attention to the ability of the I/M software to identify that particular product.  Hobby shop simulators will not be easily identified and we can not fool ourselves into catching them but the 'legitimate' commercially available products should be able to be kept in line and held to a output that makes them identifiable.
		page 7 and 8   for Mode 9 the M9P1, M9P3 and M9P5 for number of messages and M9P2, M9P4 and M9P6 with multiple packets.			Fixed.
		page 11  pull the the KOER part of the bulb check to this page after all of the scanning is done,  ask if it is on only once and then tabulate the results.  I think another KOEO test is unnecessary.			I disagree with only asking for it once.  Oregon data suggests a lot of inspects F*** this up by saying MIL is on when it is really an ABS light, maintenance light, service VEHICLE soon light, or other non-OBD II light.  I think if the electronic status says MIL is off and only the tech visual inspection says it failed, it is worth making him double check.  The only legitimate case for this to happen is a serial communication failure and only on some cars so this is extremely rare.
	Dan Grenn	1.  Page 3, 5th block down.  Should read "Mode 01 PID 00"
	Dan Grenn	2.  Page 3....Test procedure assumes that PID 00 results from each controller on any particular vehicle is a constant and unchangeable. While this appears to be a good asumption and actually is a good one for every GM product built to date and every other manufacturers product so far as well, there is nothing in ISO 15031 which requires this.   We will have to keep an eye on future product to avoid any problems.  For example, I could imagine a single softare and calibration which is able to determine merely by looking at data available to it if a particular sensor is OEM equipped or not.  If not, the PID Count would be one less than on the almost identical vehicle with the sensor installed.  Or....alternatively you could change the ISO spec to require constant PID counts and  you might suggest to the ISO spec creators to make this a requirement.
	Dan Grenn	3.  Page 3.....If I were to use PID count to help identify clean screen fraud, I would set it up so that I did not need to know precisely how many PIDs were reported and how many and which controllers were reporting them. Instead, I would simply begin be recording the type of vehicle, the Mode 09 calibration IDs and logging this information along with the PID count(s). I would store this information in the database for each vehicle I test. It should converge rather quickly with only a few dozen initial samples of any particular type of vehicle.  Then once it has converged, any vehicle brought in after that time of the same type and same calibration IDs would fail if the PID count(s) does not match the "Learned" PID count(s).
	Dan Grenn	4.  Page 5.  2nd Decision block down left side is missing the YES and NO indicators.
	Dan Grenn	5.  Page 6.  For vehicles supporting more than one ECU which supports Mode 01 PID 01, the Not_Ready_Monitor_Counter should not be incremented twice if the same monitor in mutiple controllers is supported and not ready.  In other words, under not circumstances should any single monitor be penalized for being resident in to independent ECUs.  The maximum that Not_Ready_Monitor Counter could be under even the most extreme case is 11 even if there was an ECU controlling each cylinder independently and 2 more ECUs (one monitoring Bank 1 Catalyst and another monitoring Bank 2 Catalyst).   I think you get the point by now.....