CN108737342B - 一种协议解析方法及装置 - Google Patents

一种协议解析方法及装置 Download PDF

Info

Publication number
CN108737342B
CN108737342B CN201710260836.9A CN201710260836A CN108737342B CN 108737342 B CN108737342 B CN 108737342B CN 201710260836 A CN201710260836 A CN 201710260836A CN 108737342 B CN108737342 B CN 108737342B
Authority
CN
China
Prior art keywords
data
protocol data
protocol
diagnosis
task
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201710260836.9A
Other languages
English (en)
Other versions
CN108737342A (zh
Inventor
刘均
于超峰
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shenzhen Launch Technology Co Ltd
Original Assignee
Shenzhen Launch Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shenzhen Launch Technology Co Ltd filed Critical Shenzhen Launch Technology Co Ltd
Priority to CN201710260836.9A priority Critical patent/CN108737342B/zh
Publication of CN108737342A publication Critical patent/CN108737342A/zh
Application granted granted Critical
Publication of CN108737342B publication Critical patent/CN108737342B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/03Protocol definition or specification 
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22Parsing or analysis of headers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Small-Scale Networks (AREA)
  • Maintenance And Management Of Digital Transmission (AREA)

Abstract

本发明适用于通信技术领域,提供了一种协议解析方法及装置,包括:实时操作系统对数据发送任务和数据接收任务进行调度,所述数据发送任务用于发送协议数据请求,所述数据接收任务用于接收广播数据和/或请求的协议数据;在所述数据发送任务发送协议数据请求时,基于所述协议数据请求设置过滤器,所述数据接收任务在接收到广播数据或请求的协议数据时,检测所述广播数据或所述请求的协议数据是否满足诊断需求;对满足诊断需求的广播数据和/或请求的协议数据进行解析,获取诊断需求的数据。通过上述方法能够方便车辆使用者进行故障诊断。

Description

一种协议解析方法及装置
技术领域
本发明属于通信技术领域,尤其涉及一种协议解析方法及装置。
背景技术
目前,随着生活水平的提高,汽车也日益普及,车辆的维护和保养变得越来越重要。然而,由于绝大多数车辆使用者都不是汽车专业技术领域的人士,故很难及时发现车辆中的故障。因此,便携式的车辆诊断设备有助于车辆使用者对车辆的故障及时进行诊断和保养。车辆诊断设备一般通过车辆总线电子设备与车辆内部进行通信,从而完成读取车辆电子控制单元中的数据等任务。
在当前的汽车诊断设备和车辆总线电子设备中,基本上只针对某款车型做专用的协议解析工具。例如,乘用车J1979协议、商用车J1939协议、私有CAN总线协议或诊断协议。而在当前市场中,同一辆车的CAN总线中,往往包含不止一种协议,很多车辆中即有符合国际标准的ISO15765协议,也有车厂自定义的私有诊断协议、因此,现有的车辆诊断系统及方法通常仅支持某一种通信协议,不能应用于多种车型,从而使得车辆使用者无法方便、准确的对车辆进行故障诊断。
发明内容
有鉴于此,本发明实施例提供了一种协议解析方法及装置,以解决现有技术中通常仅支持某一种通信协议,从而使得车辆使用者无法方便、准确的对车辆进行故障诊断。
本发明实施例是这样实现的,一种协议解析方法,所述协议解析方法包括:
实时操作系统对数据发送任务和数据接收任务进行调度,所述数据发送任务用于发送协议数据请求,所述数据接收任务用于接收广播数据和/或请求的协议数据;
在所述数据发送任务发送协议数据请求时,基于所述协议数据请求设置过滤器;
所述数据接收任务在接收到广播数据或请求的协议数据时,检测所述广播数据或所述请求的协议数据是否满足诊断需求;
对满足诊断需求的广播数据和/或请求的协议数据进行解析,获取诊断需求的数据。
本发明实施例的另一目的在于提供一种协议解析装置,所述协议解析装置包括:
任务调度单元,用于实时操作系统对数据发送任务和数据接收任务进行调度,所述数据发送任务用于发送协议数据请求,所述数据接收任务用于接收广播数据和/或请求的协议数据;
设置单元,用于在所述数据发送任务发送协议数据请求时,基于所述协议数据请求设置过滤器;
检测单元,用于所述数据接收任务在接收到广播数据或请求的协议数据时,检测所述广播数据或所述请求的协议数据是否满足诊断需求;
解析单元,用于对满足诊断需求的广播数据和/或请求的协议数据进行解析,获取诊断需求的数据。
本发明实施例与现有技术相比存在的有益效果是:本发明实施例通过实时操作系统对数据发送任务和数据接收任务进行调度,所述数据发送任务用于发送协议数据请求,所述数据接收任务用于接收广播数据和/或请求的协议数据,支持多种协议数据,并且,在所述数据发送任务发送协议数据请求时,基于所述协议数据请求设置过滤器,所述过滤器与所述协议数据对应,以便所述数据接收任务中接收相应的协议数据,防止数据丢失。所述数据接收任务在接收到广播数据或请求的协议数据时,检测所述广播数据或所述请求的协议数据是否满足诊断需求,对满足诊断需求的广播数据和/或请求的协议数据进行解析,最终获取诊断需求的数据,实现了对多种协议数据进行解析,该方法适用于多种车型,从而使得车辆使用者可以方便、准确的对车辆进行故障诊断,提高了用户体验。
附图说明
为了更清楚地说明本发明实施例中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1是本发明实施例提供的一种协议解析方法的实现流程图;
图2是本发明实施例提供的另一种协议解析方法的实现流程图;
图3是本发明实施例提供的一种协议解析装置的结构框图。
具体实施方式
以下描述中,为了说明而不是为了限定,提出了诸如特定系统结构、技术之类的具体细节,以便透彻理解本发明实施例。然而,本领域的技术人员应当清楚,在没有这些具体细节的其它实施例中也可以实现本发明。在其它情况中,省略对众所周知的系统、装置、电路以及方法的详细说明,以免不必要的细节妨碍本发明的描述。
为了说明本发明所述的技术方案,下面通过具体实施例来进行说明。
实施例一
图1示出了本发明第一实施例提供的一种协议解析方法的流程图,详述如下:
步骤S101,实时操作系统对数据发送任务和数据接收任务进行调度,所述数据发送任务用于发送协议数据请求,所述数据接收任务用于接收广播数据和/或请求的协议数据。
其中,实时操作系统(Real Time Operating System,RTOS)是指当外界事件或数据产生时,能够接受并以足够快的速度予以处理,其处理的结果又能在规定的时间之内来控制生产过程或对处理系统做出快速响应,调度一切可利用的资源完成实时任务,并控制所有实时任务协调一致运行的操作系统。实时操作系统包括FreeRTOS(FreeReal TimeOperating System,嵌入式实时操作系统)、uCOS(Micro Control Operation System,实时多任务操作系统)以及RTX(Real TimeeXtension,实时操作系统)等。
在本发明实时例中,可采用STM32芯片或Freescale芯片,在Windows平台下采用KEIL开发工具,移植RTX系统。
为实现在同一CAN总线下解析多种通信协议,所述步骤S101之前包括:
A1、在实时操作系统启动时,初始化CAN总线。具体地,在实时操作系统启动时,对CAN总线进行初始化包括模式寄存器的设置、中断方式的设置、波特率的设置、错误警告以及发送优先级模式寄存器的设置等。
具体地,RTX系统启动时,初始化CAN的总线,对CAN总线的波特率进行初始化设置,然后通过“os_tsk_create_user(tsk,prio,stk,size)”创建两个任务,一个是用于发送协议数据请求的数据发送任务,一个是用于接收广播数据和/或请求的协议数据的数据接收任务,其中,广播数据包括J1939协议数据,请求的协议数据包括J1979协议数据和私有诊断协议数据,RTX系统对数据发送任务和数据接收任务进行调度。可选地,数据发送任务的优先级高于数据接收任务的优先级。
步骤S102,在所述数据发送任务发送协议数据请求时,基于所述协议数据请求设置过滤器。
其中,所述过滤器与所述协议数据对应。具体地,本发明实施例中,在数据发送任务发送协议数据请求时设置与请求的协议数据相应的过滤器,数据发送任务发送的协议数据请求的不同,过滤器过滤掉的协议数据也不同,即,过滤器基于协议数据请求过滤相应的协议数据。例如,在数据发送任务发送J1979协议数据请求时,设置过滤器将除J19179协议数据之外的协议数据过滤掉,从而方便数据接收任务接收J19179协议数据。在数据发送任务发送私有诊断协议数据时,设置过滤器将除私有诊断协议数据之外的协议数据过滤掉,从而方便数据接收任务接收私有诊断协议数据。设置相应过滤器的目的在于,方便数据接收任务能从众多的协议数据中接收到数据发送任务请求的协议数据,避免数据丢失影响诊断需求协议数据的获取和解析。
步骤S103,所述数据接收任务在接收到广播数据或请求的协议数据时,检测所述广播数据或所述请求的协议数据是否满足诊断需求。
在本发明实施例中,当所述广播数据为J1939协议数据时,所述步骤S103包括:
B1、获取诊断需求的全部协议数据类型。进一步地,将全部协议数据类型置为FALSE。
B2、获取所述J1939协议数据中符合诊断需求的协议数据及数据类型。
B3、检测是否已获取到诊断需求的全部协议数据类型。
B4、若未获取到诊断需求的全部协议数据类型,则保留符合诊断需求的协议数据,进一步地,将符合诊断需求的协议数据的标识位置为TRUE,此时,缺少的协议数据的标识位依然为FALSE。所述数据发送任务发送协议数据请求缺少的协议数据,所述数据接收任务继续接收协议数据,直至获取到诊断需求的全部协议数据。
具体地,在本发明实施例中,RTX系统启动后,一直在持续发送广播数据,如,持续发送J1939协议数据,此时,数据接收任务持续接收J1939协议数据。根据获取的诊断需求的全部协议数据类型,从J1939协议数据中获取符合诊断需求的协议数据及数据类型。例如,诊断需求的全部协议数据类型包括车速、转速与油耗,若从J1939协议数据中获取了车速数据、转速数据和油耗数据,则执行步骤S104。若只获取了车速数据和转速数据,未获取到油耗数据,则保留符合诊断需求的协议数据,即保留车速数据和转速数据,此时,数据发送任务发送协议数据请求,请求油耗数据,所述数据接收任务继续接收协议数据,直至获取到油耗数据。
可选地,因车辆运行中各种协议数据会不断更新,为及时获取更新的协议数据,所述步骤B4包括:
B41、在数据发送任务中,在预设时长内按照指定周期循环发送协议数据请求。
具体地,若未从广播数据中获取到诊断需求的全部协议数据类型,则保留广播数据中符合诊断需求的协议数据,同时,在数据发送任务中,在预设时长内按照指定周期循环发送协议数据请求,从而及时获取更新后的协议数据,提高诊断的准确性。
可选地,当所述数据发送任务发送协议数据请求包括J1979协议数据和私有诊断协议数据时,所述B4包括:
B401、打开过滤器,过滤掉所述广播数据和私有诊断协议数据,只接收J1979协议数据。
B402、获取所述J1979协议数据中符合诊断需求的协议数据及数据类型。
B403、若获取到诊断需求的全部协议数据类型,则关闭所述过滤器。
B404、若未获取到诊断需求的全部协议数据类型,则重置所述过滤器,过滤掉所述广播数据和所述J1979协议数据,只接收私有诊断协议数据。
B405、获取所述私有诊断协议数据中符合诊断需求的协议数据及数据类型。
B406、若获取到诊断需求的全部协议数据类型,则关闭所述过滤器,以便进行下一轮数据获取。
具体地,在本发明实施例中,若未从广播数据如J1939协议数据中获取到诊断需求的全部协议数据类型,例如,只接收到车速数据和转速数据,未接收到油耗数据,则所述数据发送任务发送协议数据请求时,打开过滤器,过滤掉所述J1939协议数据和私有诊断协议数据,只接收J1979协议数据,从J1979协议数据中获取油耗数据,若获取到油耗数据,则关闭所述过滤器,以便进行下一轮数据获取。若未获取到油耗数据,则重置所述过滤器,此时,过滤器将J1939协议数据和J1979协议数据过滤掉,只接收私有诊断协议数据,从私有诊断协议数据中继续获取协议数据,若获取到诊断需求的全部协议数据类型,则关闭所述过滤器,以便进行下一轮数据获取。
本发明实施例中,先从广播数据中获取诊断需求的数据,若获取的数据还不满足诊断需求,则由数据发送任务请求协议数据,直至获取到诊断需求的全部协议数据,同时,通过在数据发送任务中设置相应过滤器,过滤掉不需要的协议数据,提高了数据接收任务接收协议数据的准确性。
步骤S104,对满足诊断需求的广播数据和/或请求的协议数据进行解析,获取诊断需求的数据。
具体地,将满足诊断需求的广播数据和/或请求的协议数据进行解析,获取诊断需求的数据。
具体地,以一个应用场景为例,车辆使用者需要从车辆上获取车速、转速、总里程、油耗等数据。诊断设备上的RTX系统启动后初始化CAN总线,例如波特率,创建数据发送任务和数据接收任务,数据接收任务优先处理接收到J1939协议数据,此时,车速、转速、总里程以及油耗的标识位均为FALSE。若从J1939协议数据获取到车速数据和转速数据,则将车速和转速的标识位置为TRUE,数据发送任务发送J1979协议数据请求,此时,打开过滤器,将J1939协议数据过滤掉,以便数据接收任务仅接收J1979协议数据,若从J1979协议数据中获取到了总里程数据,则将总里程的标识位置为TRUE,此时,油耗数据的标识位依然为FALSE,因此,数据发送任务发送私有诊断协议数据请求,数据接收任务从私有诊断协议数据中获取到油耗数据后,将油耗的标识位置为TRUE,此时,将过滤器关闭,方便进行下一轮数据获取。将获取的车速数据、转速数据、总里程数据以及油耗数据进行解析,获取诊断需求的数据。
本发明第一实施例中,通过实时操作系统对数据发送任务和数据接收任务进行调度,所述数据发送任务用于发送协议数据请求,所述数据接收任务用于接收广播数据和/或请求的协议数据,支持多种协议数据,如J1939协议数据、J1979协议数据以及私有诊断协议数据,并且,在所述数据发送任务发送协议数据请求时,基于所述协议数据请求设置过滤器,所述过滤器与所述协议数据对应,以便所述数据接收任务中接收相应的协议数据,防止数据丢失。所述数据接收任务在接收到广播数据或请求的协议数据时,检测所述广播数据或所述请求的协议数据是否满足诊断需求,对满足诊断需求的广播数据和/或请求的协议数据进行解析,最终获取诊断需求的数据,实现了对多种协议数据进行解析,该方法适用于多种车型,从而使得车辆使用者可以方便、准确的对车辆进行故障诊断,提高了用户体验。
实施例二
图2示出了本发明第一实施例提供的一种协议解析方法的流程图,详述如下:
步骤S201,在实时操作系统启动时,初始化CAN总线的波特率。
步骤S202,实时操作系统对数据发送任务和数据接收任务进行调度,所述数据发送任务用于发送协议数据请求,所述数据接收任务用于接收广播数据和/或请求的协议数据。
本发明实施例中,步骤S202的具体步骤参见实施例一步骤S101,在此不再赘述。
步骤S203,在所述数据发送任务发送协议数据请求时,基于所述协议数据请求设置过滤器。其中,所述过滤器与所述协议数据对应。
本发明实施例中,步骤S203的具体步骤参见实施例一步骤S103,在此不再赘述。
步骤S204,所述数据接收任务在接收到广播数据或请求的协议数据时,检测所述广播数据或所述请求的协议数据是否满足诊断需求。
本发明实施例中,步骤S204的具体步骤参见实施例一步骤S103,在此不再赘述。
步骤S205,对满足诊断需求的广播数据和/或请求的协议数据进行解析,获取诊断需求的数据。
本发明实施例中,步骤S205的具体步骤参见实施例一步骤S104,在此不再赘述。
步骤S206,将诊断需求的数据通过串口的方式发送至上位机。
本发明实施例中,通过串口的方式将诊断需求的数据发送至上位机,数据传输速度快,提高了诊断的效率。其中,上位机包括终端平台,如移动终端APP等。
本发明第二实施例中,首先在实时操作系统启动时,初始化CAN总线的波特率,通过实时操作系统对数据发送任务和数据接收任务进行调度,所述数据发送任务用于发送协议数据请求,所述数据接收任务用于接收广播数据和/或请求的协议数据,支持多种协议数据,如J1939协议数据、J1979协议数据以及私有诊断协议数据,并且,在所述数据发送任务发送协议数据请求时,基于所述协议数据请求设置过滤器,所述过滤器与所述协议数据对应,以便所述数据接收任务中接收相应的协议数据,防止数据丢失。所述数据接收任务在接收到广播数据或请求的协议数据时,检测所述广播数据或所述请求的协议数据是否满足诊断需求,对满足诊断需求的广播数据和/或请求的协议数据进行解析,最终将获取的诊断需求的数据通过串口的方式发送至上位机,该方法适用于多种车型,从而使得车辆使用者可以方便、准确的对车辆进行故障诊断,提高了用户体验。
应理解,上述实施例中各步骤的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本发明实施例的实施过程构成任何限定。
实施例三
对应于上文实施例所述的方法,图3示出了本发明实施例提供的一种协议解析装置的结构框图,该装置可应用于智能终端,该智能终端可以包括经无线接入网RAN与一个或多个核心网进行通信的用户设备,该用户设备可以具有移动设备的计算机等,例如,用户设备可以是便携式、袖珍式、手持式、计算机内置的或者车载的移动装置,它们与无线接入网交换语音和/或数据。又例如,该移动设备可以包括智能手机、平板电脑、个人数字助理PDA、车载电脑等。为了便于说明,仅示出了与本发明实施例相关的部分。
参照图3,该装置包括:任务调度单元31,设置单元32,检测单元33,解析单元34,其中:
任务调度单元31,用于实时操作系统对数据发送任务和数据接收任务进行调度,所述数据发送任务用于发送协议数据请求,所述数据接收任务用于接收广播数据和/或请求的协议数据;
设置单元32,用于在所述数据发送任务发送协议数据请求时,基于所述协议数据请求设置过滤器。其中,所述过滤器与所述协议数据对应。
检测单元33,用于所述数据接收任务在接收到广播数据或请求的协议数据时,检测所述广播数据或所述请求的协议数据是否满足诊断需求。
解析单元34,用于对满足诊断需求的广播数据和/或请求的协议数据进行解析,获取诊断需求的数据。
可选地,所述广播数据为J1939协议数据,所述检测单元33包括:
需求类型获取模块,用于获取诊断需求全部的协议数据类型。
第一数据获取模块,用于获取所述J1939协议数据中符合诊断需求的协议数据及数据类型。
检测模块,用于检测是否已获取到诊断需求的全部协议数据类型。
第二数据获取模块,用于若未获取到诊断需求的全部协议数据类型,则保留符合诊断需求的协议数据,所述数据发送任务发送协议数据请求,所述数据接收任务继续接收协议数据,直至获取到诊断需求的全部协议数据。
可选地,所述第二数据获取模块,还用于在数据发送任务中,在预设时长内按照指定周期循环发送协议数据请求。
可选地,所述数据发送任务发送协议数据请求包括J1979协议数据和私有诊断协议数据,所述第二数据获取模块包括:
第一过滤器启动模块,用于打开过滤器,过滤掉所述广播数据和私有诊断协议数据,只接收J1979协议数据。
第三数据获取模块,用于获取所述J1979协议数据中符合诊断需求的协议数据及数据类型。
第一过滤器关闭模块,用于若获取到诊断需求的全部协议数据类型,则关闭所述过滤器。
过滤器重置模块,用于若未获取到诊断需求的全部协议数据类型,则重置所述过滤器,过滤掉所述广播数据和所述J1979协议数据,只接收私有诊断协议数据。
第四数据获取模块,用于获取所述私有诊断协议数据中符合诊断需求的协议数据及数据类型。
第二过滤器关闭模块,用于若获取到诊断需求的全部协议数据类型,则关闭所述过滤器,以便进行下一轮数据获取。
可选地,所述协议解析装置还包括:
初始化单元,用于在实时操作系统启动时,初始化CAN总线。
可选地,所述协议解析装置还包括:
发送单元,用于将诊断需求的数据通过串口的方式发送至上位机。
本发明第三实施例中,本发明实施例通过实时操作系统对数据发送任务和数据接收任务进行调度,所述数据发送任务用于发送协议数据请求,所述数据接收任务用于接收广播数据和/或请求的协议数据,支持多种协议数据,并且,在所述数据发送任务发送协议数据请求时,基于所述协议数据请求设置过滤器,所述过滤器与所述协议数据对应,以便所述数据接收任务中接收相应的协议数据,防止数据丢失。所述数据接收任务在接收到广播数据或请求的协议数据时,检测所述广播数据或所述请求的协议数据是否满足诊断需求,对满足诊断需求的广播数据和/或请求的协议数据进行解析,最终获取诊断需求的数据,实现了对多种协议数据进行解析,该方法适用于多种车型,从而使得车辆使用者可以方便、准确的对车辆进行故障诊断,提高了用户体验。
所属领域的技术人员可以清楚地了解到,为了描述的方便和简洁,仅以上述各功能单元、模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能单元、模块完成,即将所述装置的内部结构划分成不同的功能单元或模块,以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中,上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。另外,各功能单元、模块的具体名称也只是为了便于相互区分,并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述或记载的部分,可以参见其它实施例的相关描述。
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。
在本发明所提供的实施例中,应该理解到,所揭露的装置和方法,可以通过其它的方式实现。例如,以上所描述的系统实施例仅仅是示意性的,例如,所述模块或单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口,装置或单元的间接耦合或通讯连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)或处理器(processor)执行本发明实施例各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围,均应包含在本发明的保护范围之内。

Claims (8)

1.一种协议解析方法,其特征在于,所述协议解析方法包括:
实时操作系统对数据发送任务和数据接收任务进行调度,所述数据发送任务用于发送协议数据请求,所述数据接收任务用于接收广播数据和/或请求的协议数据;
在所述数据发送任务发送协议数据请求时,基于所述协议数据请求设置过滤器,其中,所述过滤器与协议数据对应,所述过滤器基于协议数据请求过滤相应的协议数据,所述数据发送任务发送的协议数据请求的不同,所述过滤器过滤掉的协议数据也不同,所述过滤器用于方便所述数据接收任务从众多的协议数据中接收到所述数据发送任务请求的协议数据;
所述数据接收任务在接收到广播数据或请求的协议数据时,检测所述广播数据或所述请求的协议数据是否满足诊断需求;
对满足诊断需求的广播数据和/或请求的协议数据进行解析,获取诊断需求的数据;当所述广播数据为J1939协议数据时,所述数据接收任务在接收到广播数据时,检测所述广播数据是否满足诊断需求,包括:
获取诊断需求全部的协议数据类型;
获取所述J1939协议数据中符合诊断需求的协议数据及数据类型;
检测是否已获取到诊断需求的全部协议数据类型;
若未获取到诊断需求的全部协议数据类型,则保留符合诊断需求的协议数据,所述数据发送任务发送协议数据请求,所述数据接收任务继续接收协议数据,直至获取到诊断需求的全部协议数据。
2.如权利要求1所述的协议解析方法,其特征在于,所述若未获取到诊断需求的全部协议数据类型,则保留符合诊断需求的协议数据,所述数据发送任务继续发送协议数据请求,所述数据接收任务继续接收协议数据,直至获取到诊断需求的全部协议数据,包括:
在数据发送任务中,在预设时长内按照指定周期循环发送协议数据请求。
3.如权利要求1所述的协议解析方法,其特征在于,所述数据发送任务发送协议数据请求包括J1979协议数据和私有诊断协议数据,所述若未获取到诊断需求的全部协议数据类型,则保留符合诊断需求的协议数据,所述数据发送任务继续发送协议数据请求,所述数据接收任务继续接收协议数据,直至获取到诊断需求的全部协议数据,包括:
打开过滤器,过滤掉所述广播数据和私有诊断协议数据,只接收J1979协议数据;
获取所述J1979协议数据中符合诊断需求的协议数据及数据类型;
若获取到诊断需求的全部协议数据类型,则关闭所述过滤器;
若未获取到诊断需求的全部协议数据类型,则重置所述过滤器,过滤掉所述广播数据和所述J1979协议数据,只接收私有诊断协议数据;
获取所述私有诊断协议数据中符合诊断需求的协议数据及数据类型;
若获取到诊断需求的全部协议数据类型,则关闭所述过滤器,以便进行下一轮数据获取。
4.如权利要求1至3任一项所述的协议解析方法,其特征在于,所述协议解析方法还包括:
在实时操作系统启动时,初始化CAN总线。
5.一种协议解析装置,其特征在于,所述协议解析装置包括:
任务调度单元,用于实时操作系统对数据发送任务和数据接收任务进行调度,所述数据发送任务用于发送协议数据请求,所述数据接收任务用于接收广播数据和/或请求的协议数据;
设置单元,用于在所述数据发送任务发送协议数据请求时,基于所述协议数据请求设置过滤器,其中,所述过滤器与协议数据对应,所述过滤器基于协议数据请求过滤相应的协议数据,所述数据发送任务发送的协议数据请求的不同,所述过滤器过滤掉的协议数据也不同;
检测单元,用于所述数据接收任务在接收到广播数据或请求的协议数据时,检测所述广播数据或所述请求的协议数据是否满足诊断需求;
当所述广播数据为J1939协议数据时,所述检测单元包括:
需求类型获取模块,用于获取诊断需求全部的协议数据类型;
第一数据获取模块,用于获取所述J1939协议数据中符合诊断需求的协议数据及数据类型;
检测模块,用于检测是否已获取到诊断需求的全部协议数据类型;
第二数据获取模块,用于若未获取到诊断需求的全部协议数据类型,则保留符合诊断需求的协议数据,所述数据发送任务发送协议数据请求,所述数据接收任务继续接收协议数据,直至获取到诊断需求的全部协议数据;
解析单元,用于对满足诊断需求的广播数据和/或请求的协议数据进行解析,获取诊断需求的数据。
6.如权利要求5所述的协议解析装置,其特征在于,所述第二数据获取模块,还用于在数据发送任务中,在预设时长内按照指定周期循环发送协议数据请求。
7.如权利要求5所述的协议解析装置,其特征在于,所述数据发送任务发送协议数据请求包括J1979协议数据和私有诊断协议数据,所述第二数据获取模块包括:
第一过滤器启动模块,用于打开过滤器,过滤掉所述广播数据和私有诊断协议数据,只接收J1979协议数据;
第三数据获取模块,用于获取所述J1979协议数据中符合诊断需求的协议数据及数据类型;
第一过滤器关闭模块,用于若获取到诊断需求的全部协议数据类型,则关闭所述过滤器;
过滤器重置模块,用于若未获取到诊断需求的全部协议数据类型,则重置所述过滤器,过滤掉所述广播数据和所述J1979协议数据,只接收私有诊断协议数据;
第四数据获取模块,用于获取所述私有诊断协议数据中符合诊断需求的协议数据及数据类型;
第二过滤器关闭模块,用于若获取到诊断需求的全部协议数据类型,则关闭所述过滤器,以便进行下一轮数据获取。
8.如权利要求5所述的协议解析装置,其特征在于,所述协议解析装置还包括:
初始化单元,用于在实时操作系统启动时,初始化CAN总线。
CN201710260836.9A 2017-04-20 2017-04-20 一种协议解析方法及装置 Active CN108737342B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201710260836.9A CN108737342B (zh) 2017-04-20 2017-04-20 一种协议解析方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710260836.9A CN108737342B (zh) 2017-04-20 2017-04-20 一种协议解析方法及装置

Publications (2)

Publication Number Publication Date
CN108737342A CN108737342A (zh) 2018-11-02
CN108737342B true CN108737342B (zh) 2021-04-30

Family

ID=63933420

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710260836.9A Active CN108737342B (zh) 2017-04-20 2017-04-20 一种协议解析方法及装置

Country Status (1)

Country Link
CN (1) CN108737342B (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111353719A (zh) * 2020-03-11 2020-06-30 深圳市元征科技股份有限公司 一种诊断任务的执行方法、装置、设备及介质
CN111447231B (zh) * 2020-03-28 2022-05-10 深圳市元征科技股份有限公司 一种车辆协议识别的方法及装置
CN112859818A (zh) * 2021-01-22 2021-05-28 深圳市轩宇车鼎科技有限公司 汽车诊断方法和装置

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101430557B (zh) * 2008-12-05 2012-08-08 中国汽车技术研究中心 用于汽车故障诊断的多协议数据转换器及诊断处理方法
CN102780713A (zh) * 2011-05-09 2012-11-14 上海通用汽车有限公司 车辆诊断系统及方法
US8788731B2 (en) * 2012-07-30 2014-07-22 GM Global Technology Operations LLC Vehicle message filter
US20150312380A1 (en) * 2014-04-29 2015-10-29 General Motors Llc Translating cellular protocols for a vehicle telematics unit
CN105116871B (zh) * 2015-07-10 2017-12-29 深圳市元征科技股份有限公司 信号传输电路和汽车诊断系统的通讯装置
CN105242532A (zh) * 2015-08-20 2016-01-13 魏宇 汽车远程启动控制系统的自适应协议解析方法

Also Published As

Publication number Publication date
CN108737342A (zh) 2018-11-02

Similar Documents

Publication Publication Date Title
CN105589719B (zh) 一种远程升级整车车载控制器软件的系统及升级方法
CN107848522B (zh) 用于将诊断命令传输至交通工具的系统和方法
CN109656172B (zh) 一种获取波特率的方法、装置
CN108737342B (zh) 一种协议解析方法及装置
US20040112124A1 (en) Method for carrying out a telediagnosis on a motor vehicle, vehicle diagnosis module and service center
CN112286170B (zh) 车辆ecu刷写方法、装置、设备及存储介质
CN110545220B (zh) 汽车诊断协议检测方法及相关产品
EP2302597B1 (en) Programmable on-board vehicle diagnostic system
CN106878292A (zh) 控制方法,控制装置、车载设备和交通运输工具
CN109933051A (zh) 一种汽车诊断软件配置方法、系统、设备及计算机介质
EP4191355A1 (en) Uds-based communication method, ecu and upper computer
CN102780713A (zh) 车辆诊断系统及方法
KR20150144623A (ko) 스마트폰을 이용한 차량용 소프트웨어 갱신 방법 및 시스템
US9174648B2 (en) System for using short text messaging for remote diagnostic
US20190147668A1 (en) Server side security preventing spoofing of vin provisioning service
CN108390863B (zh) 一种数据处理方法及装置
CN108445860B (zh) 诊断设备、诊断请求处理方法及计算机可读存储介质
CN113038421A (zh) 一种汽车诊断方法、汽车诊断装置及汽车网关
US20180300966A1 (en) Automatic Configuration of Telematic Data Transmissions of a Motor Vehicle
CN105005539A (zh) 使用消息鉴别码在微控制器处鉴别数据
CN110493294A (zh) 车载电路模块的更新方法、系统、可读存储介质、及终端
Ring et al. Evaluation of vehicle diagnostics security–implementation of a reproducible security access
CN111447231B (zh) 一种车辆协议识别的方法及装置
CN106775818B (zh) 基于can总线的ecu升级方法及ecu升级设备
CN111221317B (zh) 一种汽车诊断数据处理方法和系统

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant