由于在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通道模式。如下圖所示：
注意：
?、僭贒TS的命名規范中，是不存在空格形式的，可以用英文下劃線代替或者首字母大寫。
?、谶@里選擇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選項被勾選。
?、谟行┓帐切枰獙ositive 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的內容一些我們是可以在上層容器層中直接引用，部分本層獨有的需要在本層定義引用。具體定義如下：
?、僭贒ata dictionary specification中選擇Data object properties，新建new data。鍵入參數名稱(此名稱是根據實際使用屬性定義，建議按照規范命名)，其定義結果如下：
注意：Data Type以及method Type。
?、趯ompu-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服務的完整搭建。
