ODIS使用技巧

一、ODIS使用中关于年款选择的一点说明

大家在使用ODIS过程中会遇到程序自动识别的车辆年款与实际不符，这是由于德国大众的VIN码（底盘号、车架号）定义规则与上汽大众的不同而造成的：

VIN码的第十位是年份代码，但是德国大众和上汽大众的定义规则不同：

德国大众：定义为年款

上汽大众：定义为生产年份

例如同样是15年生产的车辆，上汽大众VIN码的第十位一定是F（15年生产），而德国大众VIN码第十位有可能是F（15款）也有可能是G（16款）

由于程序中使用的是德国大众VIN码定义规则：年款（车辆识别界面也可以看出翻译为年款），因此在自动识别车辆过程中会发生程序识别到的年款与车辆实际年款不符的情况。

以刚上市的新帕为例：

一辆15年生产的16款新帕，上汽大众规则下VIN码第十位为F，因此程序自动识别为15款（实际应该使用16款程序）

这时需要手动识别为16款

否则由于不同年款配置更改，会造成部件不能诊断甚至无法识别。（如：16款新帕55大灯由氙气变为LED，增加了6D电动尾门等；若识别为15款，这些部件都会识别不了。）

因此，在发生车辆配置与实际识别到的不符时，需要切换到手动识别下一个年款（如15变为16），这样车辆才能正常诊断。

年份代码对照表：

2012（C）

2013（D）

2014（E）

2015（F）

2016（G）

2017（H）

……

二、检测计划介绍&为什么要使用引导性故障查询

2月份的文章中，我们为大家普及了引导性故障查询程序的知识，大家应该对引导性故障查询程序的功能和作用有了一定了解。但是，大家可能对从何处选择引导性故障查询程序和为什么要使用引导性故障查询的认识比较陌生。本篇文章就在介绍检测计划的过程中给大家解开这两个疑惑。

首先，给大家介绍如何使用引导性故障查询：

使用引导性故障查询要求大家在车辆识别时选择 用引导性故障查询工作。

也许大家会觉得这样做浪费时间，但是却能避免很多问题。下面我们就给大家介绍为什么我们推荐这样操作：

1. 识别完成后可以直观看出车辆都有哪些诊断地址，并且这些诊断地址中哪些有故障。

这里有时会碰到无法通信、诊断地址无法识别的故障。这可能是由于大家的5054或者控制器插头没有接好；由于电脑上安装了安全软件等破坏了诊断数据；其他原因诊断数据损坏；或者这个版本的诊断数据本身的问题。遇到这个情况请反馈到InfoCC热线：4001662886。

2. 所有与DTC（故障代码）关联的引导性故障查询程序都会显示在检测计划中。

这里有可能遇到故障码无解释并且没有连接引导性故障查询程序。这个问题大部分都是由于诊断数据的错误引起的，遇到这种情况请大家保存好引导性故障查询的诊断协议，反馈给InfoCC或者技术支持老师或者诊断股的老师，汇总之后会统一解决诊断数据的问题。（以后的文章我们会为大家介绍引导性故障查询诊断协议的重要性，如果没有这些资料可能就判断不了原因，问题就会一直存在。）

引导性故障查询为什么重要？

介绍重要性之前，我们来看看如何添加检测计划：

a） 在检测计划表签中点击 选择自己的检测计划 按钮；在弹出的检测一览窗口点击 放大镜 图标；

从检测一览窗口我们可以看出检测计划中我们可以选择到所有的引导性功能、自诊断、特殊功能等几乎ODIS所有的程序。

b） 在弹出的搜索框中输入要选择的执行元件、传感器、ECU代码等关键词后回车（这里我们以传感器G76为例），搜索结果中会列出与关键词有关的所有程序，选择想要的程序，点击 转至 按钮；

c） 就会自动定位到检测一览中程序位置；选择条目点击 加入检测计划 按钮就可以将程序添加到检测计划列表中。

关于如何通过树形目录选择检测计划，看文章末尾。

那么为什么是有引导性故障查询重要呢？请看下面的例子：

车辆自检之后检测计划中有一条关于 G31-增压压力传感器 故障的条目，但是在自行添加检测计划时，却搜索不到这样的程序！！！

这是由于该程序只有在部件有故障时才会用到，因此工程师将程序隐藏了，在ECU中存在故障码时才会激活显示！！并且，诊断时不使用引导性故障查询的话，即使识别控制器时显示了故障代码，也不会有跳转程序的连接！！

并且使用引导性故障查询进行诊断时，由于车辆会自检完所有控制器，因此可以避免由于部件识别不全或者错误造成防盗匹配，刷新的错误。

这就是为什么使用引导性故障查询如此重要。希望大家能够按照标准流程使用引导性故障查询。（这只是重要性之一，引导性故障查询其他的重要性会在介绍诊断协议的文章中为大家普及。）

附：如何通过目录选择检测计划
1. 点击具有诊断能力的系统

2. 找到诊断地址55 大灯，展开目录。

3. 展开电气部件

4. 找到G76 加入检测计划。

这种方法要求大家有一定技术水平，希望大家好好磨练维修技能。

三、ODIS诊断协议结构介绍 & 为何需要诊断协议

大家在工作中有时会遇到刷新不成功、防盗匹配失败、或者程序不能运行、某个故障代码没有代码文本，等现象。这时大家在联系技术支持等部门时，我们的工程师会让大家提供运行引导性故障查询的诊断协议。可能大家会觉得这样麻烦，但是这中诊断协议却是我们判断问题的重要材料，接下来我们就给大家简要介绍运行引导性故障查询诊断协议的结构，及这样的诊断协议能够提供给我们什么信息：

1.诊断报告的开头：

这里有两个重要信息：右侧的诊断报告发送时间和报告类型（引导性故障查询）。我们让大家提供的诊断报告必须是引导性故障查询的诊断报告，因为只有这中诊断报告才包含我们所需的信息。

2. 维修站信息：

3. 诊断仪信息：

这里包含了两个很重要的信息：ODIS版本和诊断数据版本，由于有很多人描述不清自己装的是什么版本的数据，这个信息对我们判断信息是很重要的。

4. 车辆信息：

从这里我们可以读到车型项目的信息，判断车型信息与大家报告问题时描述的一致。若底盘号（自动）和底盘号（手动）不一致，说明在诊断过程中切换过车辆。

5. 系统测试结果：

显示诊断地址识别的结果，包含了控制器软硬件信息、编码、故障代码等信息。若有故障代码没有文本，也可以从这些条目中读出。并且在刷新失败等故障发生时，这里的软硬件信息是我们判断问题原因的重要资料。

6. 检测计划列表：

若系统测试中检测到故障代码，则相应的检测计划就会罗列在这里。并且我们也看出大家是否运行了检测计划。

7. 功能检测：

这里罗列了所有引导性故障查询、引导性功能、自诊诊断的运行结果。通过分析结果中调用的功能、运行结果。我们可以知道程序运行失败是，到底是大家的操作、或者程序问题、或者零件问题、或是其他问题造成程序运行的失败。

以上就是诊断报告的大致结构，通过介绍大家对引导性故障查询诊断报告的重要性会有一定了解，并且诊断报告中的信息是车辆状态和程序运行过程的真实反映，能够更加准确判断故障原因。希望大家在读完本文之后能够培养在线发送诊断协议和保存引导性故障查询诊断协议的意识。

本文来源于：ODIS使用技巧-变化吧门户
特别声明：以上文章内容仅代表作者本人观点，不代表变化吧门户观点或立场。如有关于作品内容、版权或其它问题请于作品发表后的30日内与变化吧联系。