由于在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服務的完整搭建。