开通VIP，畅享免费电子书等14项超值服
首页
好书
留言交流
下载APP
联系客服
2023.06.12上海
目录
为了便于学习ISO14229UDS诊断协议，提供三个资源链接：
0前言
1诊断用例
2Vector诊断解决方案
2.1诊断解决方案-CANdelaStudio
2.2诊断解决方案-ODXStudio
2.3诊断解决方案–CANdelaStudio/ODXStudio建议
2.4诊断解决方案–嵌入式诊断
2.5诊断解决方案–自动生成的测试
2.6诊断解决方案–手动测试支持
2.7诊断解决方案–刷写工具
3结尾
a)【图解UDS】UDS汽车诊断标准协议（ISO14229）带你入门到精通
b)ISO14229-Part1，2，3，4，5，6，7UDS最新标准文件获取路径
c)ISO14229Roadvehicles—Unifieddiagnosticservices(UDS)标准各Part部分修订和发布状态汇总
下面给大家介绍的是Vector诊断全流程解决方案。讲解主要分为以下几个部分：诊断的使用案例；Vector解决方案以及小结。
在诊断流程中，ECU供应商根据整车厂的诊断需求以及ECU自身功能需求开发的诊断功能，生产售后会使用ECU或者说整个车辆的一个诊断功能。
诊断流程遵循“V-L型”的一个开发和使用流程，“V”是指开发阶段，从需求定义到代码实现，到集成测试；L是指生产售后阶段是使用诊断功能的一个阶段。
就好比驿站传书这个游戏一句话或者一幅图，每个人用自己的语言描述给下一个人，往往最后一个人描述的东西和第一个人会有很大的一个偏差。
基于这样的问题，Vector提出一种以机器可读的诊断数据库为核心的诊断开发全流程解决方案。
CANdelaStudio用于编辑机器可读的诊断数据库CDD文件的工具，在编辑CDD文件的时候我们需要有一个Template，也就是CDDt来保证我们CDD文件的一个有效性。
CDDt所对应的其实是主机厂提供的一个整车级别的诊断需求规范，而每一个CDD文件对应的是每一个ECU的一个诊断需求规范，所以CDDt通常会有两种可能，第1种，有一些主机厂向Vector定制了他们相对应的这个CDDt文件，或者他们自己有自己编辑好的这个相对应的CDDt文件，他可以直接释放给系统供应商去编辑CDD文件，另外也会有一些主机厂，它不提供CDDt文件。
所以VectorCANdelaStudio工具里面会自带这个Vector标准的一个CDDt文件，那么，在用户在编辑的时候，可以基于Vector标准的CDDt文件去编辑自己需要的CDDt，然后再建立自己需要的一个CDD文件。
诊断数据库里面有3大部分的内容：ECUInformation通信参数的部分；Diagnosticclass诊断服务的部分；States定义的就是我们会话安全集的部分。
服务的部分，每一条服务都有一个窗口来进行一个编辑，那每一个服务下面相对应的这个参数呢，也都有相对应的标签页来进行编辑，比如说当前这个窗口里面就是我们DTC的一个编辑的界面。
第3个部分我们会话和安全集状态的一个设置，会话和安全集是两个独立的状态，这两个状态呢，在CDD文件里面会有两个独立的表格，在这个表格里面可以针对你每一条服务精确到每个Subfunction，精确到每一个DID，来建立你在某一个会话，某一个安全集下，是否可以执行，或者涉及到相应的状态跳转，在状态跳转机制设置好后，我们可以有图形化的显示，来显示你相对应的状态之间，通过什么样的服务来进行跳转，那我们可以直观的去检查，我们的状态跳转是否正确。
CANdelaStudio除了可以去建立CDD文件以外，也可以支持多种文件的一个导入和导出，在这里呢，大家可能比较关心的一个是CDD可以导出ODX文件，另外呢就是CDD可以导出ARXML文件，那CDD可以导出的是国际标准的ODX2.0.1，2.1.0和2.2.0。
ODX全称OpenDiagnosticDataExchange(开放式的诊断数据交互格式)，一开始是由ASAM组织提出的，那也就是我们通常所说的什么ODX2.0.1，ODX2.2.0，其实指的是ASAM当时定义的ODX的一个标准编号。
现在我们所读到的ISO22901这个ODX标准是基于ASAM的ODX2.2.0来进行定义的，ODX标准里面，它定义4个部分的内容，第一个是UML建模，通过这种建模语言，来描述不同的层级不同的参数之间的一个关联关系，那在实际使用的时候呢，是将UML建模转换成XML结构，也就是ODX文件，实质上是一种XML语言结构的一个文件。
第3个部分当然会有一些文本的描述在标准里面，第4个部分呢就是我们的校验规则，ODX作为一种国际标准的数据库交互格式，不同的层级存放什么样的内容，怎么样怎么样去定义，我相应的这些数据都是有相应的一些规则的，那么都是需要进行校验的。
在描述一个ODX文件的时候，我们需要注意的是，ODX标准本身它定义的很宽泛，你可以把它想象成它是描述了一个100%的内容，而每一个工具，不同家的工具在实现ODX的时候，它可能都会满足其中的可能70~80%这样一个需求，就会造成工具A和工具B之间能够相互兼容其实只有每个中间的一部分并不能够相互兼容彼此的100%，那这个时候当然我们主机厂在使用ODX这个文件的时候，肯定是希望我所有的工具供应商都能满足我释放的同一份ODX文件，所以这个时候需要定义企业级的ODX规范，也就是ODXGuideline，也就是ODX实现指南，来定义好我这家企业所需要的ODX文件是什么样的，然后来让我不同的工具供应商来基于这份企业级规范满足不同一个ODX需求。
ODXStudio是我们用于编辑ODX文件的一个工具，它可以同时编辑ODX2.0.1和ODX2.2.0两个格式，这两个版本之间是相互不兼容的。
ODXStudio的一个编辑界面，每个层级都是一个独立的标签页，ODX-D，-C，-V，-F，-E，-FD。
那每一个层级：-D定义出来我可以把它保存成一个ODX-D的文件；-F可以保存成ODX-F的文件等等，当然我们通常在使用一个ODX文件的时候，可能同时需要ODX-D和ODX-C包含在一起，所以这个时候在标准里面还有一种格式，就是PDX，Pack的ODX，打包的ODX文件，这个格式文件可以一个或多个的ODX文件，后缀名就是.pdx。
刚刚我们介绍的CDD，ODX是两种诊断数据库文件，那我们在什么样的情况下，去使用哪一种数据库文件呢，Vector有如下的一种建议。
我们建议在开发阶段使用CDD文件，而在生产后售后阶段使用ODX文件，为什么会有这样的建议呢，我们在开发阶段数据会一直变动，或者说我们的数据库文件会一直需要不断的进行修改，那相较于ODX文件，CDD文件是面向工程性的，所以它的可编辑性更强，而且行业内大部分人对CDD文件还是比较熟悉的，所以它编辑起来会更简单更容易一些，而到了我们生产售后阶段，我们可能会有不同的Tester的一个应用，那么这个时候我们需要一种国际标准的格式能够被不同的Tester去进行使用，去进行调用，那么这个时候我们就可以选择从前期开发阶段的CDD文件导出相对应的ODX文件，来应用到我们生产和售后阶段，然后适应我们不同Tester的需求。
而对于主机厂这边，首先主机厂可能也会开发一部分的ECU，所以我们也可以同样的流程通过CDD文件导入到我们的代码配置工具里面去做相应的代码生成以及我们相应的CANOE等工具里面去做这个测试的部分，另外到生产售后阶段，我们每一个主机厂都会有自己的不同的Tester，甚至说每个阶段都会有不同的Tester，那么我们可以通过CDD格式文件通过CANdelaStudio导出符合相对应的Tester需求的一些数据库文件，比如说ODX比如说主机厂自定义诊断数据库格式来应用我们不同的Tester里面。
这样的一个“”是经历过相应的一些实际案例的一个检验的，首先我们来看福特，福特有自己的一个格式MDX，这个诊断数据库文件它不是通过福特的某一个工具直接生成的，而是通过CANdelaStudio定义的CDD文件导出福特自己的MDX文件，那福特在前期ECU开发的时候或者说他建议他的ECU供应商去进行ECU开发的时候会使用CDD，然后使用我们的CANdesk这个这样一个代码包，然后来做相应的诊断功能的开发。
到了他的生产售后阶段，它们会有自己的MDX相应的一些验证工具，会有他们自己相应的一些售后工具，EOL工具等等，那他们就通过CDD导出的MDX文件来应用到它们不同的一些部门里面，应用到不同的工具里面，那这个呢也符合我们刚刚说的前期开发阶段使用CDD文件。而生产售后阶段呢，就使用它们自定义的格式文件。
刚刚说到的是主机厂，那么对于系统供应商呢？采埃孚之前也有定制过相应的它们自己的一个CDD文件，这个CDD文件用于他们前期的开发和测试的工作，而到了交付给主机厂或者他们后端自己需要的一些工具的时候，就会把CDD导出相对应的ODX文件，或者主机厂需要的一些CDD文件交付给主机厂，然后或者是采埃孚可以通过他们自己的CDD，导出相对应的一些工具需要的ODX文件，XML，Excel相对应的一些Template。
这个是我们对于两种数据库文件的一个建议，在我们需求定义好以后，下面一步就是做代码的实现，那么在代码实现的部分，Vector提供有嵌入式代码。
在诊断功能实现以后，我们就要对它来进行测试，那有两种测试方法，第1种是自动化测试，第2种是手动测试，我们首先来看自动化测试。
Diva生成的测试用例，分两个部分，首先一个部分呢是标准工具自带的相应的测试点与我们的需求进行一个匹配，相交叉的这个点就会生成相对应的测试用例，那当然我不能保证这里生成的测试用例可以满足你100%的需求，比如说像NRC的优先级，就是我们标准的CANOE.Diva工具测不了的。
那么这个时候，我们可以由用户自己来提供相应的测试需求或者说测试规范，我们以项目服务的方式来开发CANOE.DivaPlugin，来扩展Diva自动化测试的测试用例，那目前呢，我们在全球已经有超过给15家这个OEM定制过相应的Diva扩展的测试用例。
Diva当中的配置主要包括，像工程配置，工程配置包括像我们是否这个工程是CAN的网络，然后我们的27服务使用到的Dil文件的加载，以及CANOE环境文件加载等等。
那对于刷写的测试呢，我们是从CANOE.Diva4.0版本开始支持的，它需要调用我们的vFlash工具所做的一个vFlash一个工程，完整的一个刷鞋的工程来进行测试，它可以对有效的刷写流程进行测试，也可以在刷写流程当中去制造一些故障，然后来看我们的刷写是否会被停止，以及我们的ECU是否可以重新被刷写等等。
这个界面显示的呢，就是我们生成的一个测试报告的一个界面，那我们具体的每一条测试用例是否通过，具体的测试条目，具体的一些测试步骤以及相对应的trace窗口，都会在我们报告当中去显示。
下面来看手动测试的部分，
Indigo这个工具是以我们的USKS作为一个导向，也就是说我们平常的诊断仪，手持式的诊断仪，可能是针对我们每一个车型来定制相对应的诊断仪的功能，但是Indigo这个工具，它是更换不同的车型，我只需要跟换我车型相对应的这个CDD或者ODX文件就可以。以此来生成相对应的数据导向的功能。
同时呢，它也可以加载C#脚本所编辑的一个VectorDiagnosticScripting来管理相应的诊断序列。
这个是Indigo的一个GUI界面，可以看到在这个界面里面，DTCAuditor显示是每个ECU分别由多少个DTC，当然这边还有一个可以由另外一个窗口具体显示我每一个ECU里面具体一些DTC的信息，这个窗口描述的是，我们DID相对应的一些数据，当然这个是我们Trace的原始报文，而这边显示的呢，是我们已经解析好的相对应的一些数据，那我们可以看到Indigo为了更好的方便我们中国用户的使用，所以我们Indigo从4.6版本开始，是支持中文的一个界面。
Indigo除了是现场的一个诊断仪以外，它也可以支持一个远程的介入，通常我们的整车试验场或者说我们车辆可能在外地，然后我们的诊断专家他可能在另外一个城市，那这个时候如果诊断专家需要去获取到车辆的一些信息的时候，我诊断专家通常都是出差到本地去做一些诊断的工作，但是这个时候我诊断专家比较忙，现场也比较紧急，这样一些情况的话，这个时候通过远程的方式来连接，那现场端IndigoAccessPoint这个现场端然后连接我们的这个接口卡，然后去连接我们的车辆，然后通过WiFi连上后台的服务器，远程专家这端也是任然应用的Indigo这个工具，只是带有IndigoRemotelicense，然后去用WIFI连上我们后台的服务器，两个之间相互对接上。
我们的IndigoAccessPoint这端会有一个账户和密码，我的远程端去输入这个账户跟密码，就可以知道我是跟哪一个IndigoAccessPoint端去进行连接，那这个时候我们还会有一个问题，就是现场这个车辆上面放一台电脑放一个接口卡其实是不太方便的，所以这个时候我们有另外一个自带操作系统的接口卡VN8810，它可以直接替代我的现场端和接口卡的两个部分，直接连上车辆的OBD口，并且OBD直接给它供电，同时通过WIFI连上后台的服务器，那还是一样的，我的remote远程专家发送相应的指令，获取相应的一些诊断信息。
那么这个是我们传统的两端都基于PC机的IndigoRemote系统的一个界面。
那我们可以将我们的这个刷写工程保存成一个Pack&Go的一个格式，也就是vFlashPack，这个vFlash相当于是一个打包好的一个工程，然后这个工程里面会包含你的，比如说Seed&Key文件，你的刷写文件，你的vFlashTemplate等等，全部包含在里面，那这个vFlashPack可以直接被vFlash打开，然后去进行刷写执行，也可以被其他的工具比如说Diva进行直接的调用。
vFlash是针对单个ECU进行刷写，尤其是像在产线上1对1的刷写的话效率是不太高的，所以我们有另外一个license，就是vFlashstation。vFlashstation可以调用vFlashPack实现对多个的同时刷写，最多的是8个ECU，也就是8个独立的物理通道。vFlashstation它提供的不是一个标准的含GUI的工具，而是一个函数库，这个函数库包含C和C#的API，那么你在产线上通常会有一个中控机制，那你可以把这个vFlashstation功能嵌入到你相对应的这个中控机制里面，那采用这个C或者是C#上的一个API去调用相对应的功能。
除了vFlashstation以外，它还有另一个扩展的License，就是vFlashRemote，它和我们刚刚讲到的IndigoRemote类似，是一个远程刷写的方案。那么我们需要一个vFlash的现场端，现场端提供这个ID和密码，让我远程端去输入我的IP和密码，同时连上服务器，那么我就知道我们两端可以连接上，然后我的vFlashRemote这一端，加载我的这个vFlashPack工程，然后传输到我的现场端，然后去执行相应刷写的动作。
同样的我们的现场端也可以用VN8810直接去连接我们的车辆。
欢迎大家给我留言，如果觉得好，动动你的手指，“点赞”+“收藏”