由于在DTS的使用说明文档中仅是以英文形式给出了简略的创建ODX过程。为便于用户使用Venice，下面我们将以图文形式对如何在DTS Venice中创建ODX模板进行更为详细的介绍。同时以创建一个22服务作为举例，为大家讲解如何完整的建立service。
1、创建project过程
一个project就是一个项目，这个过程是在system configurator下完成的，具体打开方式如下：开始→所有程序→Diagnostic Tool Set→System Configurator。打开界面如下：
这里务必要注意自己的license时效，若已过时间，请及时与我们的相关人员联系，获取最新的license。进入project administration界面，其中你会发现在软件安装完成后，已经存在的几个例子项目。右键任一project均可选择Open in Venice选项在Venice中打开进行定义和修改。
在其左侧框内右键new project开始创建项目。
这里要特别声明一下的是，一般情况下我们选择的都是ODX 2.2.0版本的template，因为这是目前最新的模板。也可以根据实际需要选择适合自己的版本。打开模板后会出现以下protocol选项：
若是使用的CAN通道就选择(ISO_14229_3_on_15765_2),若是DOIP格式就选择对应的协议内容，既可以选择一个也可以选择多个。区别在于，打开Venice后其内部的包含协议有区分。这里我们选择的是最为常见的CAN通道模式。如下图所示：
注意：
①在DTS的命名规范中，是不存在空格形式的，可以用英文下划线代替或者首字母大写。
②这里选择Create Default VIT的原因是，当我们不能够将详细的Vehicle Information添加到Venice中，又需要在测试工具中进行service中测试时，这个选项会帮助你模拟对应的车辆信息。
选择下一步，这样就完成了一个基础project的创建。在Venice中打开，便可以看到如下界面：
2、搭建FG层
在Venice中，为了更好的对ECU进行定义和区分，它设置了不同层次的容器层依次对其对应功能进行划分。从上到下依次为：SD(共享层Share Data)、PR(协议层Protocol)、FG(功能分组层Functional Groups)、BV(控制器基础参数层ECU Base Variants)、EV(控制器参数层ECU Variants)五个容器层。这五者之间可以理解为层层继承的关系，也可以单独存在。继承关系为了避免数据冗余以及后期扩展。
我们可以在Diagnostic Layer Containers中右键新建创建新的DLC。命名规范为DLC_所在容器层_名称。
注意：FG层是要在Functional Groups下新建new DiagLayer选择就好。这里我们要注意的是先把每一层之间的继承关系建立起来。双击任一层均可以打开它的继承关系窗口进行选择和替换。例如PR层它的继承关系如下图所示：
我们看到它实际上已经与SD层的相关内容建立了继承。我们要做的就是将他的下一层FG层与其建立联系。
注意：FG层也可以跳跃继承SD层的内容。
3、搭建BV层
在Diagnostic Layer Containers中右键新建创建新的DLC。命名规范为DLC_所在容器层_名称。
创建完成后在对应的容器层下新建new ，选择已经定义好的ShortName，创建即可。打开之后我们便会看到同样的继承选项。选择上一层FG层即可。
4、创建22服务
这里我们以ACM中的Airbag Active进行举例。具体步骤如下:
4.1定义service
Diagnostic Communication中选择Diagnostic services右键new data，定义Short Name以及Long Name。Name的定义本身要按照规范来，这样便于后期的查找修改。其基本定义如下：
一般情况下，我们需要对Diagnostic Class、Semantic、Addressing、Transmission Mode以及Protocol进行定义。这里要注意的两个点是：①我们要注意Audience部分如下图
有些情况下，Audience是并不可以每一个选项都包含的类似于10服务的Audience就仅有Development选项被勾选。
②有些服务是需要对Positive Response Suppressable Bit Mask以及Parameter Reference进行引用的。例如10服务。
4.2 Request定义
对request部分进行定义，类比于service创建，只需要在requests下右键new data对Name进行定义，其定义方式为在后续添加_Req即可。重点是parameter部分定义，其定义结果如下：
这里重点是parameter type选择以及semantic定义。然后按照规范对每一个Req的字节位数、数据种类等等进行定义。这里尤其要注意的是encoding部分(这是好多初学者忽略之处)，如下图：
具体每一个encoding含义请参照Venice说明文档。
以下是DID定义部分：
我们会发现，Bit Length为16位，encoding为Undefined。每一个Req其涵盖内容均会有所差异，还请仔细研究。
4.3 Positive Response定义
同理，右键new data，Name部分增加_Pos，其SID定义部分如下图所示：
其DID部分定义如下图所示：
我们发现，其parameter type改为Matching Request Param，这是为了与request部分进行匹配，要对起始位与字节位数进行定义。
每一个服务均会在positive response中涵盖本身通讯的parameter，此服务的参数简写为AA，即Airbag Active。其定义结果如下图，涉及到DOP参数定义环节。
其中DOP-Base Ref的内容一些我们是可以在上层容器层中直接引用，部分本层独有的需要在本层定义引用。具体定义如下：
①在Data dictionary specification中选择Data object properties，新建new data。键入参数名称(此名称是根据实际使用属性定义，建议按照规范命名)，其定义结果如下：
注意：Data Type以及method Type。
②对Compu-Method进行定义，定义结果如下：
某些DOP还需要对constraints部分进行limit设置。完成对DOP设置，回到AA定义环节，进行引用即可。
4.4 Negative Responses定义
区别于以上两个设定的是，在Negative中首先需要定义NRID(即Negative Response ID)定义如图所示：
然后定义SID，这里的SID作用是matching，其定义界面如下：
注意：各Byte Length，Bit Position的数值选择。
其次是NRC(Negative Response Code)的定义，这里我们便引用的是在SD层下定义的DOP，详细设置如图所示：
这里的NRC包含所有需要对Negative Response进行code说明的数据，我们可以通过右键go to的方法进入DOP设置界面，可以发现大量的code定义数据。
也可以在constriants中看到对应的scale constraint。最后是NRCC(Negative Response Code Const)定义，设置界面如下图所示
注意：BytePosition决定于上面三个parameter所占用的BitLength;CodeValue每一个是有对应含义的，其具体对应关系请研究ASAM14229协议。这样，我们就完成了所有相关部分的设置。返回Diagnostic Service界面。
4.5 完成引用，进行check
在Diagnostic Service找到自己定义的service，将对应的request、positive response 、negative response依次通过右键new data的方式进行添加。
然后选择check工具。检查无误，记得保存。
这样我们就完成了Venice下一个22服务的完整搭建。
