（一）组态开发第一阶段

    组态方式的开发经历了2个阶段，第一阶段是以模块为独立开发单元的阶段，每个模块的开发过程是独立的，模块间的开发工作互不干扰，每个模块的开发工作包含以下内容：

    1．配置基本通讯参数，包括配置ECU的通讯ID，通讯协议，通讯引脚，通讯速率，长短帧等。

    2．配置指令及返回参数的解析方式，逐条建立指令，并对控制器的回复数据按模块规范要求进行解析。

      3．配置显示方式，配置需要加载的指令以及显示的参数列表，参数的显示名称，显示方式，显示顺序，显示单位等。

    4．酉己置DTC指令，配置DTC数据库，配置DTC code及解析方式，配置FTB及解析方式，配置DTC status及解析方式。

    5．配置流程框图，对复杂的流程的实现过程配置不同的控件及跳转，并在不同的控件中加载不同的指令实现条件检查，条件跳转及判断。

    这种组态开发方式的好处是，每个模块是独立开发和测试的，模块间开发和测试互不影响。缺点是有一些模块间可以复用的功能无法实现复用，造成了部分工作的重复劳动，从而降低了工作效率。

     （二）组态开发第二阶段

      为了克服以上缺点，可在现有的组态开发方式上进行以下几方面的改进：

    LDTC数据库的改进

    传统的售后诊断开发平台对故障码的相关功能都是和模块绑定的，每个模块都对应一个DTC解析表，一个FTB解析表，一个故障码状态解析表，开发人员需要把这3个表的数据逐个配置到诊断数据库中。对于数据量比较大的模块，比如ECM，其故障码大概在500～800个。传统的配置方式不仅占用开发人员的开发时间，还增大了每个模块的诊断数据文件，相应地增加了诊断数据库网络更新所需要的时间。

    分析诊断协议即可发现，故障码解析，FTB解析，故障码状态解析只和诊断协议有关，和模块无关。相同的诊断协议有相同的故障码状态的解析数据库，相同的FTB的解析数据库，相同的故障码解析数据库。只要由系统管理人员统一维护对应协议的DTC相关数据库，模块开发人员根据模块所使用的诊断协议调用相应的数据库，就可以实现对该协议的模块DTC相关功能的支持。对于模块中可能涉及的、数量较少的特殊故障码的解析，只需专门维护一个小的表格（一般不超过10个）通过对故障码数据库的解析进行覆盖就可以实现。避免了每个模块都要单独建立一个故障码数据库的问题，允许少量因各种原因导致的不符合协议的DTC的设置，既提高了工作效率，又降低了因手动逐个配置而造成的错误。

    2．对动态打包PID功能的支持

    为了提高读取模块实时参数值的速度，很多协议都支持动态PID打包功能。打包功能就是可以通过一条指令得到模块多个参数的实时值。传统的诊断平台是根据模块的诊断协议手动对PID进行打包的，如图2和图3所示。

 

    手动打包是对动态PID的指令在开发时进行预定义的，首先用打包指令打包动态PID，然后再用指令请求动态PID的值，并对控制器返回的值进行解析。由于模块的实时请求数据量大，并且每一屏实时显示数据都要重新定义，所以在开发时需要预定义很多打包指令和解析方式。这种方式复用性特别差，复用时如果增加或者删除某个参数，就需要对整个打包的动态PID指令进行拆分调整。在拆分调整过程中，每个参数的位置都要有变化，要重新定义解析方式，这部分的工作需要占据很大一部分的开发时间。

    仔细分析诊断协议，发现动态PID打包的规则也是和协议相关的。在开发诊断开发平台软件时，把和协议相关的打包规则，比如支持哪些动态PID，每个打包指令可以支持多少个字节的返回值等设置到平台中。诊断软件开发人员在实际开发过程中，只需要定义本模块是否支持动态PID打包，需要打包哪几个动态PID等等即可。在请求参数值时，后台会根据规则动态随机打包参数，并发送对应的动态PID指令，无需预定义，同时也避免了请求参数变化时开发的工作量，减少了大量的开发时间。

上一页  [1] [2] [3]  下一页