CDD的那些事 - 前言

前言

关于UDS和他的工具链们在汽车行业已经流传了20多年，如果它一直接受国内的教育的话，现在已经是大学水平了，这个比喻是为了能够形象的说明这套知识体系和应用已经达到的成熟度，一个大学在社会中已经基本具备了独立处理事情的能力了，只有一些特别复杂或者意外才需要大人出面处理了。对于UDS和他的工具链来说也是一样的。 他们在汽车行业中的应用已经根深蒂固了，目前在引用工具上最流行的肯形式的是Vector的CANOE和它的各种组件上。本文将从一个使用者的角度深入剖析一下UDS和Vector CDD的那些事。

网络与UDS和CDD相关的知识内容非常之丰富，并且也存在了大量的关于如何使用工具来制作CDD的介绍，包括来自于Vector厂家的各种材料中也都有说明，但是这些内容都相对比较零散，有的是是点对点的解决一些特殊问题，有的是概括性的描述一些基础功能，今天我们开启的这个旅程，要带领读者一步一步的依据一个UDS的诊断调查问卷做出一个CDD，即手把手教学。所以我们会尽量的摒弃一些复制粘贴已有文献成果的操作。这次我们闭门造辆车。

        如果我们将视角转化到功能层面，我们将整车的UDS功能看作一个大的系统，系统的边界是整车使用UDS的网络，我们已最为熟知的CAN作为总线，系统的要素是总线网络中各个节点的UDS功能。（系统的定义请小伙伴们自行领悟），同时我们将网络中i给你各个节点（控制器）上的UDS功能看成是每个独立的子系统。那么将这个概念再映射到Vector的工具连上，CDDT就是整车UDS功能视角的功能描述，CDD就是各个子系统的UDS的功能描述，同时CDDT中也描述了每个子系统如何进行交互并组成整车系统的环境和接口。

        CDD的全称是CANdela Diagnostic Descriptions。假设我们将Vector公司的CANOE软件作为一个系统，那么CDD文件是这个系统实现UDS功能的一个输入的配置文件或者某种程度上的数据库文件（当然这是一个具有非常复杂能力的数据库文件），CANOE是运行这个文件并实现这个文件中描述功能的环境。

        我们的目标是依据项目中的需求如“诊断调查问卷”等，开发和使用CDD文件让CANOE这个工具能够准确的理解UDS诊断调查问卷中定义的所有功能要求，假设顾客关于UDS的所有需求收敛到诊断调查问卷，那么这个文件可以作为开发CDD的输入，CDD是CANOE的输入，最终通过Diva完成对这部分功能的仿真测试。

        CDD可以通过Vecotr的编辑工具CANdelaStudio进行编辑，编辑后的文件通过Diva进行使用或者在CANOE的CFG工程中加载使用。CDD可以让Diva读懂所有的UDS诊断相关的功能要求，支持什么服务，不支持什么服务以及非常细致的参数配置。通过这个CDD文件可以将UDS在某控制器上的技术要求尽数描述清楚。

        CDDT是CDD文件的编辑模板，两者的区别在网络上有很多专家大神解读过。因此在这里同样不会再重复的搬运，会在后续的介绍中进行说明，因为只有在使用的过程中才能真正理解它们的边界是如何定义的。网络上关于CDD和CDDT的介绍大多是借用了Vector使用说明中的描述，从设计上来看，这两个文件的定义并没有很好的对结构进行可视化，让使用者能够轻易地理解在功能上的区别，目前更多的看到的是一些笼统的介绍，具体的功能点差异需要我们在使用的过程逐步识别。

        编辑CDDT需要购买单独License。我个人倒是比较能理解这个策略，认为是德国的设计，有想法。OEM作为整车功能设计Owner，应该负责每个CDDT的定义，而Tire1只需要基于OEM释放的CDDT去编辑自己负责开发的控制前上使用的CDD即可，因此通过这个License能够很好的隔离OEM和TIRE1之间的界面。

        但是如此高级的设计在中国实车并没有得到很好的使用。Local OEM项目开发过程和国外的企业差别还是比较大的，具有一定特色，，所以也有不少广大TIRE1 出钱出力购买和开发CDDT。能够从整车功能角度释放CDDT的Local OEM本就不多，再能通过这个文件对于TIRE1进行管理的就更少了，可能还是考虑到成本把，毕竟对于特殊工具的要求是有代价的。

接下来我们就从工具入手逐步揭开UDS和它的工具链门的面纱。

术语

Instance ： 定义在Diagnostic Class中的UDS Service

Service：每个Instance中的sub-function

Servies List： 每个Instance中的Services 窗口

Interace：ECU的外部通讯接口，如CAN, CANFD等