本发明涉及一种诊断仪开发方案，尤其是涉及一种基于odx文件的诊断仪开发方案。
背景技术：
随着研发车型的增多，越来越多车型的上市，势必会需要售后诊断仪的开发，按照当前模式开发，每个车型需要支付给诊断仪供应商大量的开发费。
由此为降低该部分支出，考虑开发自己的诊断仪以节省该部分支出；同时由于车型众多，如都以编码格式实现诊断功能，会导致代码冗余，工作量重复。odx文件是一种国际通用的诊断数据库，该文件能包含所有诊断信息，但其中有很多规则可以实现自定义。在odx文件中，每个对应的诊断服务都包含diagservice、请求、肯定响应、否定响应以及相对应的参数。如果不考虑每个诊断服务的分类，只是通过解析文件去获取相应的诊断服务，后续仍需要配置每个诊断服务的用途支持诊断仪开发，无法做到通用化。
如果考虑以一个标准格式诊断数据库（odx文件）囊括所有诊断信息，制定一套文件识别规则方案支持诊断仪开发工作,必然能够节约大量的开发费用,方便车企产品诊断工作,提高诊断效率,提升产品质量。
技术实现要素：
本发明针对现有技术不足，提出一种基于odx文件的诊断方法，通过制定区分诊断服务及解析诊断服务的方案，使诊断服务做到通用化，以节约开发费用，提高车企产品的诊断效率和质量。
本发明采用的技术方案：
一种基于odx文件的诊断方法，软件总体架构见附图1，主要制定区分诊断服务及解析诊断服务，其技术方案包括如下步骤：
1、解析odx获取诊断id及安全访问掩码。该方案通过识别odx-d文件中的诊断id和诊断服务掩码，为后续诊断服务提供依据，软件识别流程见附图2。
2、解析odx获取dtc列表及dtc清除读取服务。在dtcs节点下获取整车dtc列表，并通过diagservice节点中semantic="faultmemory"获取相应的诊断服务及响应。软件识别流程见附图3。
3、解析odx获取ecu基本信息诊断服务。diagservice节点中semantic="storeddata"获取相应的诊断服务及响应，根据pos-response中回复的参数显示读取到的参数。该部分诊断指令只发送一次。软件识别流程见附图4。
4、解析odx获取ecu动态数据诊断服务。diagservice节点中semantic="currentdata"获取相应的诊断服务及响应，根据pos-response中回复的参数显示读取到的参数。该部分诊断指令需循环发送。软件识别流程见附图5。
5、解析odx获取ecu执行器诊断服务。diagservice节点中semantic="control"获取相应的诊断服务及响应，再根据si="servicename"节点识别是否为读取控制目标状态、控制、返回控制。软件识别流程见附图6。
6、解析odx获取ecu配置诊断服务。diagservice节点中semantic="varcoding"获取相应的诊断服务及响应，再根据si="servicename"节点识别是否为读取、配置。软件识别流程见附图7。
发明有益效果：
1、本发明基于odx文件的诊断方法，通过制定区分诊断服务及解析诊断服务的方案，使诊断服务做到通用化，以节约开发费用，提高车企产品的诊断效率和质量。确认符合公司实际状态的规则，使诊断服务做到通用化。
2、本发明基于odx文件的诊断方法，以一个标准格式诊断数据库（odx文件）囊括所有诊断信息，制定一套文件识别规则方案支持诊断仪开发工作,能够节约大量的开发费用,方便车企产品诊断工作,可以切实提高诊断效率,提升产品质量。
3、本发明基于odx文件的诊断方法，通过识别odx文件，按照既定的规则，区分诊断服务类型，并自动生成相应的诊断页面显示诊断信息，后续诊断仪开发时，只需要导入车辆odx文件即可完成大部分诊断仪开发工作。
附图说明
图1为本发明基于odx文件的诊断方法软件总体架构示意图；
图2为本发明诊断方法解析odx获取诊断id及安全访问信息软件识别流程；
图3为本发明诊断方法dtc解析及诊断服务获取流程图；
图4为本发明诊断方法解析odx获取ecu基本信息流程图；
图5为本发明诊断方法解析odx获取ecu动态数据诊断服务软件识别流程；
图6为本发明诊断方法解析odx获取ecu执行器诊断服务软件识别流程；
图7为本发明诊断方法解析odx获取ecu配置诊断服务软件识别流程。
具体实施方式
下面通过具体实施方式，结合附图对本发明技术方案做进一步的详细描述。
实施例1
参见图1，本发明基于odx文件的诊断方法，包括如下步骤：
s1，解析odx文件，识别odx-d文件中的诊断id和诊断服务掩码，获取诊断id及安全访问掩码；
s2，解析odx获取dtc列表及dtc清除读取服务：在dtcs节点下获取整车dtc列表，并通过diagservice节点中semantic="faultmemory"获取相应的诊断服务及响应；
s3，解析odx获取ecu基本信息诊断服务：diagservice节点中semantic="storeddata"获取相应的诊断服务及响应，根据pos-response中回复的参数显示读取到的参数；
s4，解析odx获取ecu动态数据诊断服务：diagservice节点中semantic="currentdata"获取相应的诊断服务及响应，根据pos-response中回复的参数显示读取到的参数；
s5，解析odx获取ecu执行器诊断服务：diagservice节点中semantic="control"获取相应的诊断服务及响应，再根据si="servicename"节点识别是否为读取控制目标状态、控制、返回控制；
s6，解析odx获取ecu配置诊断服务：diagservice节点中semantic="varcoding"获取相应的诊断服务及响应，再根据si="servicename"节点识别是否为读取、配置。
实施例2
参见图2，本实施例的基于odx文件的诊断方法，与实施例1不同的是：步骤s1中，解析odx获取诊断id及安全访问掩码的过程包括：通过识别odx文件中包含的complex-value节点下包含的第三行数据为诊断请求id、第六行为诊断响应id；同时在根据在odx文件中的自定义内容：seed2key-type、mask1、mask2，获取模块后续再执行配置、执行器时需要过安全访问的信息。通过该步，软件开发时无需每个项目去配置模块信息。
实施例3
参见图3，本实施例的基于odx文件的诊断方法，和实施例1及实施例2不同的是：步骤s2中，通过识别odx文件dtcs节点下的所有dtc码及其含义，建立相应的故障码库；再从diagservice节点下提取sementic=“faultmemory”的服务，自动生成界面和诊断服务，再将读取到的故障码与之前建立的故障码库对比，获取故障码含义并在界面上显示。
实施例4
参见图4，本实施例的基于odx文件的诊断方法，和前述各实施例的不同之处在于：进一步的，步骤s3中，通过识别odx文件diagservice节点下sementic=“storeddata”的服务，并根据服务下面的诊断服务名称自动生成界面和诊断服务；在收到诊断服务响应中的数据后，根据数据类型解析后，在诊断界面后显示诊断结果。
实施例5
参见图5，本实施例的基于odx文件的诊断方法，和实施例4不同的是：步骤s4中，动态数据需要周期发送。同样是通过识别odx文件diagservice节点下sementic=“currentdata”的服务，并根据服务下面的诊断服务名称自动生成界面和诊断服务。在收到诊断服务响应中的数据后，根据数据类型解析后，在诊断界面后显示诊断结果。
实施例6
参见图6，本实施例的基于odx文件的诊断方法，和前述各实施例不同的是：步骤s5中，通过识别odx文件diagservice节点下sementic=“control”的服务，并根据服务下面的诊断服务名称自动生成界面和诊断服务。该服务执行分成3步，首先需执行读取服务获取当前需要控制目标的状态，并根据控制目标的类型自动生成诊断页面；然后根据页面上选取的诊断状态，执行控制指令，控制目标作出相应的动作；最后退出时执行返回控制指令，将控制目标的控制权交还给模块。
实施例7
参见图7，本实施例的基于odx文件的诊断方法，和前述各实施例不同的是：步骤s6中，通过识别odx文件diagservice节点下sementic=“varcoding”的服务，并根据服务下面的诊断服务名称自动生成界面和诊断服务。该服务执行分成2步，首先需执行读取服务获取当前需要配置内容状态，并根据配置内容的数据类型自动生成诊断页面；然后再根据实车状态选择对应的配置内容，执行写入配置内容服务，完成整车配置。
本发明基于odx文件的诊断方法，通过制定区分诊断服务及解析诊断服务的方案，以一个标准格式诊断数据库（odx文件）囊括所有诊断信息，使诊断服务做到通用化，方便车企产品诊断工作，可以切实提高诊断效率，节约开发费用。通过识别odx文件，按照既定的规则，区分诊断服务类型，并自动生成相应的诊断页面显示诊断信息，后续诊断仪开发时，只需要导入车辆odx文件即可完成大部分诊断仪开发工作。