【图解UDS】UDS汽车诊断开发流程及Vector解决方案工具链介绍

a)  【图解UDS】UDS汽车诊断标准协议（ISO 14229）带你入门到精通

b)   ISO 14229 -Part1，2，3，4，5，6，7 UDS最新标准文件获取路径

c)   ISO 14229 Road vehicles — Unified diagnostic services (UDS)标准各Part部分修订和发布状态汇总
 

下面给大家介绍的是Vector诊断全流程解决方案。讲解主要分为以下几个部分：诊断的使用案例；Vector解决方案以及小结。

汽车诊断目的是为了在有限的时间和成本下，快速获取ECU和车辆的故障信息，便于维修维护。Vector在整个诊断流程中，提供诊断方法和诊断工具以及有关的诊断服务。

诊断功能的实现以及测试，在车辆开发中越来越重要，原因呢，是因为现在的汽车网络越来越复杂，ECU越来越多，控制策略越来越复杂，每个国家也对汽车排放有相关的法规要求，为了避免故障无法排查等问题，就需要在开发阶段对车辆的诊断功能的实现和验证进行严格的处理，避免后端无法很好的使用诊断功能。

在诊断流程中，ECU供应商根据整车厂的诊断需求以及ECU自身功能需求开发的诊断功能，生产售后会使用ECU或者说整个车辆的一个诊断功能。

诊断通信是Tester和车辆的一个直接通信，所以诊断功能的实现，实际上就是两种通信的一个规则实现，而通信规则就是由我们常说的诊断协议来定义的，它定义了诊断请求响应的格式，ECU对诊断请求处理的逻辑等等，现在行业内常用的诊断协议，ISO 14229 UDS协议；ISO 15765 CAN总线诊断的传输层协议；ISO15031排放相关的OBD协议；ISO 14230 部分整车厂还会使用到的kwp2000的协议，这个协议在UDS之前常用的一种诊断协议。

诊断功能实现后，当然也需要进行测试验证，诊断测试通常有几个部分的测试：诊断协议的测试，例如报文格式的测试；传输层的测试，例如传输层相关时间参数的测试；第3个就是诊断应用的测试，例如会话安全集转换的一个测试；DID具体数值的测试等等。

诊断流程遵循“V-L型”的一个开发和使用流程，“V”是指开发阶段，从需求定义到代码实现，到集成测试；L是指生产售后阶段是使用诊断功能的一个阶段。

传统的诊断开发流程中，诊断数据的交互都是使用机器不可读的格式文件，比如Excel，PDF等，那么在整个的开发流程当中会涉及到整车厂，系统供应商，不同的公司，不同的部门，每个工程师根据自己的经验，对于同一份诊断需求文件的解读，有可能会出现偏差，例如开发工程师和测试工程师对同一句话的理解不同，则会导致测试不通过，然后又需要重新回到需求定义的部分去完善或者解释这条需求，从而导致需求定义时间过长，致使整个开发周期延长。

就好比驿站传书这个游戏一句话或者一幅图，每个人用自己的语言描述给下一个人，往往最后一个人描述的东西和第一个人会有很大的一个偏差。

基于这样的问题，Vector提出一种以机器可读的诊断数据库为核心的诊断开发全流程解决方案。

因为机器对于数据的解读，不会像人工解读有那么多经验理解在里面，可以很好的把数据传递到每一个阶段，从而保证整个开发阶段的数据的一致性，有效的缩短开发周期，机器可读的诊断数据库其实就是将传统的Excel调查表等信息编辑成CDD或ODX文件。CDD是Vector私有的一种诊断数据库格式；ODX是国际标准的诊断数据交互格式。CANdelaStudio编辑CDD文件，以及也可以导出ODX文件，ODX Studio用于编辑ODX文件，诊断数据库的编辑其实就是诊断需求的定义。在需求定义完后，代码实现可以通过诊断数据库生成诊断相关的代码以及应用层接口函数。Vector的诊断部分代码包括：Non_Autosar标准的CANdesk；以及Autosar标准的MICROSAR DIAG。

功能实现后我们有CANOE.Diva，通过获取诊断数据库中的数据定义，自动生成测试用例，然后CANOE执行测试用例并生成测试报告，CANOE，CANalyzer ，CANape可以导入诊断数据库后手动收发诊断服务或者编写诊断脚本，Indigo是Vector的一个参数化的诊断仪，另外与诊断相关的功能的刷写功能，Vector也提供刷写上位机工具vFlash，下面我们就具体来看一下相关的工具。

CANdelaStudio用于编辑机器可读的诊断数据库CDD文件的工具，在编辑CDD文件的时候我们需要有一个Template，也就是CDDt来保证我们CDD文件的一个有效性。

CDDt所对应的其实是主机厂提供的一个整车级别的诊断需求规范，而每一个CDD文件对应的是每一个ECU的一个诊断需求规范，所以CDDt通常会有两种可能，第1种，有一些主机厂向Vector定制了他们相对应的这个CDDt文件，或者他们自己有自己编辑好的这个相对应的CDDt文件，他可以直接释放给系统供应商去编辑CDD文件，另外也会有一些主机厂，它不提供CDDt文件。

所以Vector CANdelaStudio工具里面会自带这个Vector标准的一个CDDt文件，那么，在用户在编辑的时候，可以基于Vector标准的CDDt文件去编辑自己需要的CDDt，然后再建立自己需要的一个CDD文件。

诊断数据库里面有3大部分的内容：ECU Information通信参数的部分；Diagnostic class诊断服务的部分；States定义的就是我们会话安全集的部分。

我们下面具体来看这几个窗口，首先，ECU Information当中的Interfaces接口，它定义的是不同接口下的通信参数，比如说CAN接口相关的通信参数；以太网接口相关的通信参数，那都定义在我们相对应的这个接口信息里面，那所有的接口都需要在CDDt里面定义好，也就是编辑CDD文件的时候，不需要新建这个相关的接口，只需要激活你相对应的总线的接口，然后编辑你相对应的通信参数。

服务的部分，每一条服务都有一个窗口来进行一个编辑，那每一个服务下面相对应的这个参数呢，也都有相对应的标签页来进行编辑，比如说当前这个窗口里面就是我们DTC的一个编辑的界面。

第3个部分我们会话和安全集状态的一个设置，会话和安全集是两个独立的状态，这两个状态呢，在CDD文件里面会有两个独立的表格，在这个表格里面可以针对你每一条服务精确到每个Subfunction，精确到每一个DID，来建立你在某一个会话，某一个安全集下，是否可以执行，或者涉及到相应的状态跳转，在状态跳转机制设置好后，我们可以有图形化的显示，来显示你相对应的状态之间，通过什么样的服务来进行跳转，那我们可以直观的去检查，我们的状态跳转是否正确。

除了我们上面说的3个部分呢，是我们描述一个诊断需求规范必要的三个部分，另外呢CANdelaStudio也可以用来描述需求，也就是我们可以做一个需求的匹配，比如说我们从我们另外一个provision里面可以导出我们的诊断需求文件CSV，在这个需求文件里面定义了我有10条DID的一个需求，那我就可以映射到我现在定义的在CDD文件里面定义的相关的DID，然后我实际需求文档里面的DID，然后做一个匹配，然后来看一下我现在的CDD文件是否已经满足我所有的一个需求。

CANdelaStudio除了可以去建立CDD文件以外，也可以支持多种文件的一个导入和导出，在这里呢，大家可能比较关心的一个是CDD可以导出ODX文件，另外呢就是CDD可以导出ARXML文件，那CDD可以导出的是国际标准的ODX 2.0.1，2.1.0和2.2.0。

那当然，这里导出的呢，只是符合相关的ISO标准的，如果说某一个企业它有自己的一个定制化的ODX标准，那么这个时候我们是需要做一个定制化的开发，来保证相关的CDD文件可以导出符合这个企业级的ODX实现指南的。

另外呢CDD导出的arxml文件，这里的arxml文件包含的是Autosar标准里面所说的dext，也就是dextract仅仅只诊断的这个相关的部分。

ODX全称Open Diagnostic Data Exchange (开放式的诊断数据交互格式)，一开始是由ASAM组织提出的，那也就是我们通常所说的什么ODX 2.0.1，ODX 2.2.0，其实指的是ASAM当时定义的ODX的一个标准编号。

现在我们所读到的ISO 22901这个ODX标准是基于ASAM的ODX 2.2.0来进行定义的，ODX标准里面，它定义4个部分的内容，第一个是UML建模，通过这种建模语言，来描述不同的层级不同的参数之间的一个关联关系，那在实际使用的时候呢，是将UML建模转换成XML结构，也就是ODX文件，实质上是一种XML语言结构的一个文件。

第3个部分当然会有一些文本的描述在标准里面，第4个部分呢就是我们的校验规则，ODX作为一种国际标准的数据库交互格式，不同的层级存放什么样的内容，怎么样怎么样去定义，我相应的这些数据都是有相应的一些规则的，那么都是需要进行校验的。

ODX文件它包含几大类的数据，首先第一个ODX-D描述了诊断数据和诊断服务；ODX-C描述了通信参数；ODX-V描述了整车的拓扑结构，这三个部分呢是描述的诊断数据库的部分，除此以外还可以描述其他和诊断相关的一些文件，比如说ODX-F描述的是刷写数据文件，在加载传统Hex,S19，bin文件以后呢，可以添加一些Check sum，或者security等等相关的一些信息，把他封装成一个标准的ODX-F文件；ODX-E更多的呢用在主机厂生产车间里面，在车辆出厂前，对车辆进行相应的一些配置，那ODX-E描述的就是这些配置的相关数据；ODX-FD功能导向的一个ODX文件，在4S店里面通常售后阶段，我们需要不是某一个ECU相关的数据，而是车辆某一个功能的集合的这样一个数据，所以ODX-FD通常会使用在售后阶段，尤其是像4S店里面；ODX-M多ECU的Jobs，这个部分现在行业内已经没有人使用了，所以我们现在最多会用到的ODX文件会包含以下的6个部分。

在描述一个ODX文件的时候，我们需要注意的是，ODX标准本身它定义的很宽泛，你可以把它想象成它是描述了一个100%的内容，而每一个工具，不同家的工具在实现ODX的时候，它可能都会满足其中的可能70~80%这样一个需求，就会造成工具A和工具B之间能够相互兼容其实只有每个中间的一部分并不能够相互兼容彼此的100%，那这个时候当然我们主机厂在使用ODX这个文件的时候，肯定是希望我所有的工具供应商都能满足我释放的同一份ODX文件，所以这个时候需要定义企业级的ODX规范，也就是ODX  Guide line，也就是ODX实现指南，来定义好我这家企业所需要的ODX文件是什么样的，然后来让我不同的工具供应商来基于这份企业级规范满足不同一个ODX需求。

ODX Studio是我们用于编辑ODX文件的一个工具，它可以同时编辑ODX 2.0.1和ODX 2.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的需求。

这样一个建议会涉及到我们整个数据交互的流程，这个数据交互流程的核心是CDD文件，而CDD来源于实际的诊断规范。

对于ECU供应商而言，我们主要是做ECU开发，那么我们可以用CDD文件来导入到我们GENy相关的这个代码配置工具里面去做相应的代码生成，也可以把它放到我们的CANOE.Diva或者CANOE Indigo像这些工具里面去做相应的测试。

而对于主机厂这边，首先主机厂可能也会开发一部分的ECU，所以我们也可以同样的流程通过CDD文件导入到我们的代码配置工具里面去做相应的代码生成以及我们相应的CANOE等工具里面去做这个测试的部分，另外到生产售后阶段，我们每一个主机厂都会有自己的不同的Tester，甚至说每个阶段都会有不同的Tester，那么我们可以通过CDD格式文件通过CANdela Studio导出符合相对应的Tester需求的一些数据库文件，比如说ODX比如说主机厂自定义诊断数据库格式来应用我们不同的Tester里面。

这样的一个“”是经历过相应的一些实际案例的一个检验的，首先我们来看福特，福特有自己的一个格式MDX，这个诊断数据库文件它不是通过福特的某一个工具直接生成的，而是通过CANdela Studio定义的CDD文件导出福特自己的MDX文件，那福特在前期ECU开发的时候或者说他建议他的ECU供应商去进行ECU开发的时候会使用CDD，然后使用我们的CANdesk这个这样一个代码包，然后来做相应的诊断功能的开发。

到了他的生产售后阶段，它们会有自己的MDX相应的一些验证工具，会有他们自己相应的一些售后工具，EOL工具等等，那他们就通过CDD导出的MDX文件来应用到它们不同的一些部门里面，应用到不同的工具里面，那这个呢也符合我们刚刚说的前期开发阶段使用CDD文件。而生产售后阶段呢，就使用它们自定义的格式文件。

另外一个使用案例呢，是欧洲的两个主机厂之间有一个合作的项目，那么这个时候呢，在合作以前，OEM1它使用的CDD文件，而OEM2它使用的ODX文件，那么这个时候，它们两之间相互交互的时候呢？OEM1就选择用CDD导出相应的ODX文件，来跟OEM2之间来进行交互，以及相应的一些工作，那ODX本身这个文件也可以用在不同公司不同的部门之间相互的一个交互，而我们原本的CDD文件，也可以用在我们一开始的开发流程当中，不用改变它自身已有的相关的一些流程。

刚刚说到的是主机厂，那么对于系统供应商呢？采埃孚之前也有定制过相应的它们自己的一个CDD文件，这个CDD文件用于他们前期的开发和测试的工作，而到了交付给主机厂或者他们后端自己需要的一些工具的时候，就会把CDD导出相对应的ODX文件，或者主机厂需要的一些CDD文件交付给主机厂，然后或者是采埃孚可以通过他们自己的CDD，导出相对应的一些工具需要的ODX文件，XML，Excel相对应的一些Template。

这个是我们对于两种数据库文件的一个建议，在我们需求定义好以后，下面一步就是做代码的实现，那么在代码实现的部分，Vector提供有嵌入式代码。

嵌入式代码首先第一种Nun Autosar标准的Command代码，Command里面诊断的部分叫做CANdesc，它的一个实现方式就是将CDD文件导入到我们的GENy工具里面，然后去生成诊断相关的一些底层代码，以及应用层接口。

另外一种就是我们Autosar解决方案MICROSAR，其中的MICROSAR DIAG诊断的部分包含我们的DCM，DEM和FIM相关的这些模块，那它的一个实现方式也是将我们的CDD或者ODX文件导入到我们的配置工具“达芬奇”里面，自动生成和诊断相关的一些底层代码，以及应用层接口。

在诊断功能实现以后，我们就要对它来进行测试，那有两种测试方法，第1种是自动化测试，第2种是手动测试，我们首先来看自动化测试。

自动化测试是实现，我们可以用CANOE.Diva这个工具，他可以在导入诊断数据库ODX或者CDD文件的基础上去，去自动生成诊断相关的测试用例，可以覆盖UDS，KWP，GMW3110或者OBD等相关的一些测试用例。

我们可以看到这张图里面就是欧洲一个主机厂，他一个车型平台上面通过手动测试和自动测试分别所耗费的时间的一个对比图，灰色就是他手动测试所花费的时间；红色就是它自动测试所花费的时间，我们可以看到自动测试所消耗的时间，只有他手动测试的1/3，甚至更少。

CANOE.Diva的一个流程，把CDD和ODX文件导入到Diva工程当中，然后去通过一些相应的配置，点一个按钮自动生成诊断相关的一些测试用例，那这部分测试用例实际是CANOE的一个测试模块，所以需要把Diva的工程导入到CANOE当中去连接ECU，去执行这些测试用例，最终自动生成相应的测试报告。

Diva生成的测试用例，分两个部分，首先一个部分呢是标准工具自带的相应的测试点与我们的需求进行一个匹配，相交叉的这个点就会生成相对应的测试用例，那当然我不能保证这里生成的测试用例可以满足你100%的需求，比如说像NRC的优先级，就是我们标准的CANOE.Diva工具测不了的。

那么这个时候，我们可以由用户自己来提供相应的测试需求或者说测试规范，我们以项目服务的方式来开发CANOE.Diva Plugin，来扩展Diva自动化测试的测试用例，那目前呢，我们在全球已经有超过给15家这个OEM定制过相应的Diva扩展的测试用例。

标准的Diva可以测到点，包括:物理寻址和功能寻址的测试；P2，P2*，S3时间参数的测试；请求格式，响应格式，22服务里面同时读取多个DID等等相应的测试；具体数据内容的测试；ECU应用相关的测试；以及会话安全集相关转换的等等相关的测试。

Diva当中的配置主要包括，像工程配置，工程配置包括像我们是否这个工程是CAN的网络，然后我们的27服务使用到的Dil文件的加载，以及CANOE环境文件加载等等。

另外一个是测试配置，主要是配置我们测试当中的用到的一些时间参数，还有我们这些诊断服务是否要测以及我们的测试深度等等

那关于DTC这部分的配置，我们主要是通过加载DBC文件来实现网络相关的故障注入，也可以通过像VT系统，来注入一些短路，断路，或者电压等等相关的一些IO故障注入。

那对于刷写的测试呢，我们是从CANOE.Diva 4.0版本开始支持的，它需要调用我们的vFlash工具所做的一个vFlash一个工程，完整的一个刷鞋的工程来进行测试，它可以对有效的刷写流程进行测试，也可以在刷写流程当中去制造一些故障，然后来看我们的刷写是否会被停止，以及我们的ECU是否可以重新被刷写等等。

CANOE.Diva是自动生成诊断和刷写相关的测试用例的工具；而我们另外一个工具vTESTstudio是用来去编辑测试用例这样一个工具，并且他们的执行环境都是CANOE，现在我们可以把CANOE.Diva的工程，直接导到vTESTstudio里面，把他们合并到同一个测试工程，并且在此基础上添加一些Diva可能暂时还不支持的一些测试用例。

这个界面显示的呢，就是我们生成的一个测试报告的一个界面，那我们具体的每一条测试用例是否通过，具体的测试条目，具体的一些测试步骤以及相对应的trace窗口，都会在我们报告当中去显示。

下面来看手动测试的部分，

CANOE，CANape，这些工具不是主要用来做诊断的，但是呢，他们都可以在加载数据库的基础上手动收发一些诊断服务，或者去编写一些诊断相关的脚本，那我们现在具体介绍Indigo工具，Indigo是我们参数化的诊断仪，但是它是一个基于PC机的诊断仪。

Indigo这个工具是以我们的USKS作为一个导向，也就是说我们平常的诊断仪，手持式的诊断仪，可能是针对我们每一个车型来定制相对应的诊断仪的功能，但是Indigo这个工具，它是更换不同的车型，我只需要跟换我车型相对应的这个CDD或者ODX文件就可以。以此来生成相对应的数据导向的功能。

同时呢，它也可以加载C#脚本所编辑的一个Vector Diagnostic Scripting来管理相应的诊断序列。

这个是Indigo的一个GUI界面，可以看到在这个界面里面，DTC Auditor显示是每个ECU分别由多少个DTC，当然这边还有一个可以由另外一个窗口具体显示我每一个ECU里面具体一些DTC的信息，这个窗口描述的是，我们DID相对应的一些数据，当然这个是我们Trace的原始报文，而这边显示的呢，是我们已经解析好的相对应的一些数据，那我们可以看到Indigo为了更好的方便我们中国用户的使用，所以我们Indigo从4.6版本开始，是支持中文的一个界面。

Indigo除了是现场的一个诊断仪以外，它也可以支持一个远程的介入，通常我们的整车试验场或者说我们车辆可能在外地，然后我们的诊断专家他可能在另外一个城市，那这个时候如果诊断专家需要去获取到车辆的一些信息的时候，我诊断专家通常都是出差到本地去做一些诊断的工作，但是这个时候我诊断专家比较忙，现场也比较紧急，这样一些情况的话，这个时候通过远程的方式来连接，那现场端 Indigo Access Point这个现场端然后连接我们的这个接口卡，然后去连接我们的车辆，然后通过WiFi连上后台的服务器，远程专家这端也是任然应用的Indigo这个工具，只是带有Indigo Remote license，然后去用WIFI连上我们后台的服务器，两个之间相互对接上。

我们的 Indigo Access Point这端会有一个账户和密码，我的远程端去输入这个账户跟密码，就可以知道我是跟哪一个 Indigo Access Point端去进行连接，那这个时候我们还会有一个问题，就是现场这个车辆上面放一台电脑放一个接口卡其实是不太方便的，所以这个时候我们有另外一个自带操作系统的接口卡VN8810，它可以直接替代我的现场端和接口卡的两个部分，直接连上车辆的OBD口，并且OBD直接给它供电，同时通过WIFI连上后台的服务器，那还是一样的，我的remote远程专家发送相应的指令，获取相应的一些诊断信息。

这个就是VN8810自带操作系统的智能设备，以及它相关的性能参数，那么这个VN8810应用用场景主要就是远程诊断以及刷写。

那么这个是我们传统的两端都基于PC机的Indigo Remote系统的一个界面。

我们现在从需求定义到代码实现，以及到测试的部分，整个的诊断开发全流程已经覆盖到了。接下来一个，就是跟我们的诊断功能息息相关的，也就是我们ECU另外一个刷写的功能。

刷写功能的实现，首先是我们ECU本身也需要有Bootloader的代码，来支撑这个刷写的功能，当然Vector也提供相应的flash Bootloader的代码包，另外我们的vFlash是一种通用型的上位机工具，为什么说它是通用型的呢？因为我们可以支持不同的总线，包括CAN，DoIP，FlexRay等等，我们支持不同的刷写格式，比如传统的Intel-Hex，Motorola-s，Binary等等，以及ODX-F相关的这个格式，也可以支持不同的OEM刷写规范刷写序列。

为什么呢？因为我们在使用vFlash的时候需要一个基于刷写规范定制的vFlash Template，这个vFlash Template是基于这个刷写规范定制化开发的，所以它的获取方式通常会有几种。首先一个是购买了Vector Flash BootLoader我们会随包带相对应的vFlash Template；另外只是购买vFlash这个工具的话，我们可以以项目的形式定制化开发相对应的vFlash Template；其次我们在全球已经有给很多的主机厂定制了相对应的vFlash Template，那主机厂也可以把这个vFlash Template释放给你相对应的系统供应商。建立vFlash这个工程的时候，我们只需要选择对应的vFlash Template，然后加载我们的刷写数据，然后去配置一些ECU相关的配置，比如说我们CANID的定义等等（CANID，波特率等等填写），来建立一个完整的刷写工程。

那我们可以将我们的这个刷写工程保存成一个Pack&Go的一个格式，也就是vFlash Pack，这个vFlash 相当于是一个打包好的一个工程，然后这个工程里面会包含你的，比如说Seed&Key文件，你的刷写文件，你的vFlash Template等等，全部包含在里面，那这个vFlash Pack可以直接被vFlash打开，然后去进行刷写执行，也可以被其他的工具比如说Diva进行直接的调用。

这个是vFlash一个刷写过程的一个界面，它会显示我当前已经刷到了已经执行到了哪一个阶段，然后已经刷到了我的data的部分，然后当前还剩多长时间，我的一个刷新速率等等。

vFlash是针对单个ECU进行刷写，尤其是像在产线上1对1的刷写的话效率是不太高的，所以我们有另外一个license，就是vFlash station。vFlash station可以调用vFlash Pack实现对多个的同时刷写，最多的是8个ECU，也就是8个独立的物理通道。vFlash station它提供的不是一个标准的含GUI的工具，而是一个函数库，这个函数库包含C和C#的API，那么你在产线上通常会有一个中控机制，那你可以把这个vFlash station功能嵌入到你相对应的这个中控机制里面，那采用这个C或者是C#上的一个API去调用相对应的功能。

除了vFlash station以外，它还有另一个扩展的License，就是vFlash Remote，它和我们刚刚讲到的Indigo Remote类似，是一个远程刷写的方案。那么我们需要一个vFlash 的现场端，现场端提供这个ID和密码，让我远程端去输入我的IP和密码，同时连上服务器，那么我就知道我们两端可以连接上，然后我的vFlash Remote这一端，加载我的这个vFlash Pack工程，然后传输到我的现场端，然后去执行相应刷写的动作。

同样的我们的现场端也可以用VN8810直接去连接我们的车辆。

欢迎大家给我留言，如果觉得好，动动你的手指，“点赞”+“收藏”

获取更多汽车行业资讯，以及工具链的使用，可以关注微信公众号“汽车电子助手”

或者扫描下方二维码进行关注

END

工具 开发流程 vector