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