CN108427405A - 一种支持多用户操作的汽车实时诊断代理及其数据处理方法 - Google Patents

Abstract

本发明提供一种支持多用户操作的汽车实时诊断装置及其使用方法，设置的接收请求单元以及请求合并记录单元的工作进程，处理单元的工作进程，响应发送单元的工作进程，本发明是将来自多个诊断仪的外部请求进行整理，请求合并记录单元将同一类型的外部请求合并成一个，同时记录该类型的外部请求所对应的诊断仪的信息；就算有多个用户提交的同一类型外的部请求，诊断代理只发送一份给汽车；得到汽车的响应后，将响应数据发送给每个请求这项数据的用户；每个相同的诊断请求只会发送一份到汽车，汽车的诊断压力将大大降低，可以做到与单用户诊断装置相同的诊断实时性。

Description

一种支持多用户操作的汽车实时诊断代理及其数据处理方法

技术领域

本发明涉及汽车实时诊断装置领域，尤指一种支持多用户操作的汽车实时诊断代理及其数据处理方法。

背景技术

现代汽车越来越依赖汽车内部的电子控制来进行工作。同样，汽车的诊断也依赖于汽车电子诊断技术，特别随着新能源车的发展，没有电子诊断技术，汽车检测和维修基本就无法进行。

当前常用的汽车诊断装置如图1所示，将诊断代理(通常为一个硬件小设备，诊断代理在市面上可以买到，有时也叫“诊断接头”，作为诊断仪的附件存在)，通过OBDII插头与汽车OBDII诊断口连接，诊断仪(通常为专用电脑或者工业电脑或者平板电脑)通过有线与诊断代理连接，通过诊断代理，诊断仪可以对汽车各个ECU(电子控制单元)进行诊断。

在一些特定场景，比如汽车实训教学和竞赛，为了提升设备利用率，需要多个用户，比如多个参加实训的学生，需要对同一辆车同时、独立进行诊断，而不能多个用户使用同一诊断装置。如果同一辆汽车能够被多个用户(如学生)并行使用，则汽车的利用率将大大提升，实训成本将会降低。

市面上实现多用户诊断装置的方式，是基于现有单用户诊断代理改造成多用户诊断代理。如图2-3所示目前多用户汽车诊断装置，就是在诊断代理上将多个诊断仪的请求同时独立地进行处理，各个诊断仪请求和响应之间并没有关联关系。就算是每个诊断仪都请求相同的诊断响应，每个诊断仪的请求都会被发送到汽车上。

举例来说，5个诊断仪(编号为诊断仪1～5)同时工作，每个诊断仪都请求汽车的诊断数据X，则诊断代理会接收5个诊断的请求X1～X5(X1～X5分别指1～5号诊断仪发出的诊断请求X)，X1～X5都是相同的，然后诊断代理会返回5份相同的响应分别发给5个诊断仪。

由此可见，汽车在同一时间需要处理5个相同的诊断请求并进行响应，给汽车带来了很大压力，会给汽车工作带来异常。

举例来说，一辆汽车最大可以承受外部5ms一次诊断请求访问，同时有5个诊断仪同时对汽车进行诊断。为了保证诊断访问的实时性，每个一个诊断仪每20ms发送一次请求，此时CAN总线需要承受20ms/5＝4ms的请求频率，汽车会工作异常。

为了解决多用户访问操作时汽车可能异常的问题，只能降低诊断仪的请求访问频率。仍以上例子为例，诊断仪的请求访问周期必须提高到5ms*5＝25ms才能保证汽车工作不异常。如果是10个诊断仪同时工作，则必须将访问周期提高到5ms*10＝50ms。这样带来的后果是诊断的实时性降低了，对于一些实时敏感的诊断数据如油门踏板深度、刹车深度等的诊断数据采集间隔加大，诊断的效果降低。

因此既要支持多用户操作，又要支持实时性的诊断，目前市面上的诊断装置无法做到。

发明内容

为解决上述问题，本发明提供一种支持多用户操作的汽车实时诊断装置及其使用方法，在不额外增加车内设备和成本的情况下，支持多个用户同时对一辆车进行实时性的诊断。

为实现上述目的之一，本发明采用的技术方案是提供一种支持多用户操作的汽车实时诊断代理，包括用于接收多个诊断仪的外部请求并发送至请求合并记录单元的接收请求单元、将同一类型的外部请求合并并记录各类型的外部请求所对应的诊断仪信息并发送至处理单元的请求合并记录单元、用于将合并后的外部请求发送至汽车ECU，接收汽车ECU的诊断响应并将诊断响应发送至响应发送单元的处理单元、用于将同一类型的诊断响应发送给对应的诊断仪的响应发送单元；其中所述接收请求单元的输入端与多个诊断仪连接，所述接收请求单元的输出端与请求合并记录单元的输入端连接，所述请求合并记录单元的输出端与处理单元的输入端连接，所述处理单元的输出端与响应发送单元的输入端连接，所述响应发送单元的输出端与请求合并记录单元以及多个诊断仪连接。

进一步，还包括用于检测接收汽车ECU的诊断响应是否超时的第一定时响应单元，其中第一定时响应单元的输入端与请求合并记录单元连接，第一定时响应单元的输出端与处理单元连接。

为实现上述目的之二，本发明提供一种支持多用户操作的汽车实时诊断代理的数据处理方法，包括以下步骤：

S1.接收请求单元接收多个诊断仪的外部请求并发送至请求合并记录单元，请求合并记录单元将同一类型的外部请求合并并记录各类型的外部请求所对应的诊断仪信息并发送至处理单元；

S2.处理单元将合并后的外部请求发送至汽车ECU，同时接收汽车ECU的诊断响应并将诊断响应发送至响应发送单元；

S3.响应发送单元将同一类型的诊断响应发送给对应的诊断仪。

进一步地，所述步骤S1的具体步骤为：

步骤S11：初始化请求合并记录单元中的请求记录表；

步骤S12：如果接收请求单元接收到来自诊断仪的一个外部请求，跳转到步骤S13；否则继续停留在步骤S12；

步骤S13：查找请求合并记录单元中是否存在该外部请求的类型，如果没有，创建该外部请求类型，并将对应的诊断仪的诊断仪信息写入该外部请求类型中，接着跳转回步骤S12；否则跳转到步骤S14；

步骤S14：查找请求合并记录单元中该外部请求类型，如果不存在对应的诊断仪的诊断仪信息，则把对应的诊断仪的诊断仪信息加入到该外部请求类型的尾部；否则，丢弃本次外部请求，跳转到步骤S12。

其中所述步骤S2的具体步骤为：

步骤S21：处理单元查询请求合并记录单元中是否有内容非空的外部请求类型待处理，如果有，则跳转到步骤S22；否则仍停留在步骤S21；

步骤22：处理单元将待处理的外部请求类型转换成CAN总线可以识别的外部请求报文并通过CAN总线发送至汽车ECU；汽车ECU将外部请求报文进行处理并发送CAN响应至处理单元)；

步骤S221：启动第一定时响应单元，等待CAN响应；如果第一定时响应单元超时，仍未收到CAN响应，则跳转回步骤S21；如果未超时，接收到CAN响应，则跳转到步骤S23。

步骤23：处理单元将接收到的CAN响应转换成外部可以识别的诊断响应，并发送给响应发送单元；然后跳转到步骤S21；其中诊断响应与对应的外部请求类型相同。

其中所述步骤S3的具体步骤为：

步骤S31：如果响应发送单元接收到来自处理单元中发送的诊断响应，则跳转到步骤S32，否则仍停留在步骤S31继续等待；

步骤S32：诊断响应在请求合并记录单元中查找对应外部请求类型的所有诊断仪的诊断仪信息；

步骤S33：按照对应外部请求类型的所有诊断仪的诊断仪信息逐一发送诊断响应给对应的诊断仪；

步骤S34：删除请求合并记录单元中的该外部请求类型，跳转回步骤S31。

本发明的有益效果在于：将来自多个诊断仪的外部请求进行整理，请求合并记录单元将同一类型的外部请求合并成一个，同时记录该类型的外部请求所对应的诊断仪的信息；就算有多个用户提交的同一类型外的部请求，诊断代理只发送一份给汽车；得到汽车的响应后，将响应数据发送给每个请求这项数据的用户；每个相同的诊断请求只会发送一份到汽车，汽车的诊断压力将大大降低，可以做到与单用户诊断装置相同的诊断实时性。

附图说明

图1是现技术单用户的汽车诊断装置图。

图2是现技术多用户的汽车诊断装置图。

图3是现技术多用户汽车诊断装置的软件框架图。

图4是本发明诊断代理的工作原理图。

图5是本发明结构框架简略示意图。

图6是本发明结构框架具体示意图。

图7是本发明接收请求单元以及请求合并记录单元的工作进程逻辑框图。

图8是本发明处理单元的工作进程逻辑框图。

图9是本发明响应发送单元的工作进程逻辑框图。

附图标号说明：1.接收请求单元；2.请求合并记录单元；3.处理单元；4.响应发送单元。

具体实施方式

下面结合具体实施例和说明书附图对本发明予以详细说明。

请参阅图4-9所示，本发明关于一种支持多用户操作的汽车实时诊断装置及其使用方法，下面通过具体实施方式对本发明作进一步说明。

请参阅图4-6所示，为实现上述目的之一，本发明采用的技术方案是提供一种支持多用户操作的汽车实时诊断装置，包括诊断代理、OBDII接口、多个诊断仪，其中诊断代理通过OBDII接口与汽车OBDII诊断口电性连接，且所述诊断代理与多个诊断仪双向通讯连接，所述诊断代理包括用于接收多个诊断仪的外部请求并发送至请求合并记录单元2的接收请求单元1、将同一类型的外部请求合并并记录各类型的外部请求所对应的诊断仪信息并发送至处理单元3的请求合并记录单元2、用于将合并后的外部请求发送至汽车ECU，接收汽车ECU的诊断响应并将诊断响应发送至响应发送单元4的处理单元3、用于将同一类型的诊断响应发送给对应的诊断仪的响应发送单元4；其中所述接收请求单元1的输入端与多个诊断仪连接，所述接收请求单元1的输出端与请求合并记录单元2的输入端连接，所述请求合并记录单元2的输出端与处理单元3的输入端连接，所述处理单元3的输出端与响应发送单元4的输入端连接，所述响应发送单元4的输出端与多个诊断仪连接，处理单元3的输出端以及输入端分别与OBDII接口连接。

进一步，所述接收请求单元1的输入端以及响应发送单元4的输出端通过无线模块与多个诊断仪连接。进一步，所述无线模块为WLAN模块、蓝牙模块、3G/4G模块、ZIGBEE模块中的一项或多项。通过无线模块实现诊断仪和多个诊断仪之间的双向数据通讯，没有有线路搭建的烦恼。

进一步，还包括用于检测接收汽车ECU的诊断响应是否超时的第一定时响应单元，其中第一定时响应单元的输入端与请求合并记录单元2连接，第一定时响应单元的输出端与处理单元3连接。

请参阅图4-9所示，为实现上述目的之二，本发明提供一种支持多用户操作的汽车实时诊断代理的数据处理方法，包括以下步骤：

S1.接收请求单元1接收多个诊断仪的外部请求，请求合并记录单元2将同一类型的外部请求合并成一个，同时记录该类型的外部请求所对应的诊断仪的信息，并构成请求记录表；

S2.处理单元3查询请求记录表的有效请求记录，将外部请求转换为CAN请求发送给汽车ECU，同时接收汽车ECU的响应并转换为外部响应，并发送给响应发送单元4；

S3.响应发送单元4接收来自处理单元3的外部响应，查询请求合并记录单元2中的请求记录表，将外部响应发送给对应的诊断仪。

将来自多个诊断仪的外部请求进行整理，请求合并记录单元2将同一类型的外部请求合并成一个，同时记录该类型的外部请求所对应的诊断仪的信息，并构成请求记录表；就算有多个用户提交的同一类型外的部请求，诊断代理只发送一份给汽车；得到汽车的响应后，将响应数据发送给每个请求这项数据的用户；，每个相同的诊断请求只会发送一份到汽车，汽车的诊断压力将大大降低，可以做到与单用户诊断装置相同的诊断实时性。

下面通过具体实施方式对本发明作进一步说明。

每一台诊断仪具有用于区分身份的诊断仪ID，比如n台诊断仪，则n台诊断仪的诊断仪ID分别为(X1、X2......Xn)，每一种外部请求具有用于区分请求类型的外部请求ID，比如m种外部请求，则每种外部请求的外部请求ID分别为(Y1、Y2......Ym)；

其中在本具体实施方式中，某一台诊断仪的诊断仪ID为X1，该诊断仪发出的外部请求ID为Y1的外部请求；诊断仪ID为X2的诊断仪也发出外部请求ID为Y1的外部请求；

请参阅图7所示，接收请求单元1以及请求合并记录单元2的工作进程：

步骤A：初始化请求合并记录单元2中的请求记录表，初始化完后，表项里面内容全部为空；完成后跳转到步骤B；

步骤B：如果接收请求单元1接收到来自诊断仪的一个外部请求，跳转到步骤C；否则继续停留在步骤B；

步骤C：查找请求合并记录单元2中的请求记录表中是否存在该外部请求ID：Y1的索引条目，如果没有，创建该外部请求ID的索引条目，并将对应的诊断仪的诊断仪ID：X1、X2作为内容，写入该索引条目对应的内容中，接着跳转回步骤B；否则跳转到步骤D；

步骤D：查找请求合并记录单元2中的请求记录表中该外部请求ID：Y1的索引条目的内容，如果内容中不存在对应的诊断仪的诊断仪ID：X1、X2，则把对应的诊断仪的诊断仪ID：X1、X2加入到该索引条目内容的尾部；否则，丢弃本次外部请求，跳转到步骤B；

接收请求单元1以及请求合并记录单元2的工作进程为整理以及完善请求记录表，通过将来自多个诊断仪的外部请求进行整理，请求合并记录单元2将同一类型的外部请求合并成一个，同时记录该类型的外部请求所对应的诊断仪的信息，并构成请求记录表。

请参阅图8所示，处理单元3的工作进程：

步骤E：等待查询定时器定时到，如果定时器到，查询请求记录表，查询请求记录表中是否有内容非空的索引条目待处理(外部请求ID：Y1的索引条目的内容记录有诊断仪ID：X1、X2)，则跳转到步骤F；

步骤F：将待处理的外部请求ID：Y1转换成CAN总线可以识别的外部请求报文并发送到CAN总线；跳转到步骤G。

步骤G：启动第一定时响应单元，等待CAN响应；如果第一定时响应单元超时，仍未收到CAN响应，则跳转回步骤E；如果未超时，接收到CAN响应，则跳转到步骤H。

步骤H：将接收到的CAN响应转换成外部可以识别的外部响应报文ID：Y1，并发送给响应发送单元4；然后跳转到步骤E；其中外部响应报文ID：Y1与对应的外部请求ID：Y1相同；

请参阅图9所示，响应发送单元4的工作进程：

步骤I：响应发送单元4接收到来自处理单元3中发送的外部响应报文ID：Y1，则跳转到步骤J。

步骤J：以外部响应报文ID：Y1查找请求记录表，找到对应外部请求ID：Y1的索引条目中保存的所有诊断仪ID：X1、X2，跳转到步骤K；

步骤K：按照诊断仪ID：X1、X2逐一发送外部响应报文给对应的诊断仪X1、诊断仪X2，跳转到步骤L；

步骤L：删除“请求记录表”中的该外部请求ID：Y1的索引条目，跳转回步骤I。

接收请求单元1以及请求合并记录单元2的工作进程，处理单元3的工作进程，响应发送单元4的工作进程，均基于Linux多任务操作系统中进行；

综上所述接收请求单元1以及请求合并记录单元2的工作进程，处理单元3的工作进程，响应发送单元4的工作进程，本发明是将来自多个诊断仪的外部请求进行整理，请求合并记录单元2将同一类型的外部请求合并成一个，同时记录该类型的外部请求所对应的诊断仪的信息，并构成请求记录表；就算有多个用户提交的同一类型外的部请求，诊断代理只发送一份给汽车；得到汽车的响应后，将响应数据发送给每个请求这项数据的用户；每个相同的诊断请求只会发送一份到汽车，汽车的诊断压力将大大降低，可以做到与单用户诊断装置相同的诊断实时性。

假设，有m个诊断仪，且每一个诊断仪发送n个不同类型的外部请求；以下列举诊断代理所使用的“请求记录表”数据格式如下：

以上实施方式仅仅是对本发明的优选实施方式进行描述，并非对本发明的范围进行限定，在不脱离本发明设计精神的前提下，本领域普通工程技术人员对本发明的技术方案作出的各种变形和改进，均应落入本发明的权利要求书确定的保护范围内。

Claims (7)

1.一种支持多用户操作的汽车实时诊断代理，其特征在于：包括用于接收多个诊断仪的外部请求并发送至请求合并记录单元的接收请求单元、将同一类型的外部请求合并并记录各类型的外部请求所对应的诊断仪信息,并发送至处理单元的请求合并记录单元、用于将合并后的外部请求发送至汽车ECU，接收汽车ECU的诊断响应并将诊断响应发送至响应发送单元的处理单元、用于将同一类型的诊断响应发送给对应的诊断仪的响应发送单元；其中所述接收请求单元的输入端与多个诊断仪连接，所述接收请求单元的输出端与请求合并记录单元的输入端连接，所述请求合并记录单元的输出端与处理单元的输入端连接，所述处理单元的输出端与响应发送单元的输入端连接，所述响应发送单元的输出端与请求合并记录单元以及多个诊断仪连接。

2.根据权利要求1所述的一种支持多用户操作的汽车实时诊断装置，其特征在于，还包括用于检测接收汽车ECU的诊断响应是否超时的第一定时响应单元，其中第一定时响应单元的输入端与请求合并记录单元连接，第一定时响应单元的输出端与处理单元连接。

3.一种支持多用户操作的汽车实时诊断代理的数据处理方法，其特征在于，包括以下步骤：

S1.接收请求单元接收多个诊断仪的外部请求并发送至请求合并记录单元，请求合并记录单元将同一类型的外部请求合并并记录各类型的外部请求所对应的诊断仪信息并发送至处理单元；

S2.处理单元将合并后的外部请求发送至汽车ECU，同时接收汽车ECU的诊断响应并将诊断响应发送至响应发送单元；

S3.响应发送单元将同一类型的诊断响应发送给对应的诊断仪。

4.根据权利要求3所述的一种支持多用户操作的汽车实时诊断代理的数据处理方法，其特征在于：

所述步骤S1的具体步骤为：

步骤S11：初始化请求合并记录单元中的请求记录表；

步骤S12：如果接收请求单元接收到来自诊断仪的一个外部请求，跳转到步骤S13；否则继续停留在步骤S12；

步骤S13：查找请求合并记录单元中是否存在该外部请求的类型，如果没有，创建该外部请求类型，并将对应的诊断仪的诊断仪信息写入该外部请求类型中，接着跳转回步骤S12；否则跳转到步骤S14；

步骤S14：查找请求合并记录单元中该外部请求类型，如果不存在对应的诊断仪的诊断仪信息，则把对应的诊断仪的诊断仪信息加入到该外部请求类型的尾部；否则，丢弃本次外部请求，跳转到步骤S12。

5.根据权利要求3所述的一种支持多用户操作的汽车实时诊断代理的数据处理方法，其特征在于：其中所述步骤S2的具体步骤为：

步骤S21：处理单元查询请求合并记录单元中是否有内容非空的外部请求类型待处理，如果有，则跳转到步骤S22；否则仍停留在步骤S21；

步骤22：处理单元将待处理的外部请求类型转换成CAN总线可以识别的外部请求报文并通过CAN总线发送至汽车ECU；汽车ECU将外部请求报文进行处理并发送CAN响应至处理单元；

步骤23：处理单元将接收到的CAN响应转换成外部可以识别的诊断响应，并发送给响应发送单元；然后跳转到步骤S21；其中诊断响应与对应的外部请求类型相同。

6.根据权利要求5所述的一种支持多用户操作的汽车实时诊断代理的数据处理方法，其特征在于：所述步骤S22和步骤S23之间，还包括步骤S221：启动第一定时响应单元，等待CAN响应；如果第一定时响应单元超时，仍未收到CAN响应，则跳转回步骤S21；如果未超时，接收到CAN响应，则跳转到步骤S23。

7.根据权利要求3所述的一种支持多用户操作的汽车实时诊断代理的数据处理方法，其特征在于：

其中所述步骤S3的具体步骤为：

步骤S31：如果响应发送单元接收到来自处理单元中发送的诊断响应，则跳转到步骤S32，否则仍停留在步骤S31继续等待；

步骤S32：诊断响应在请求合并记录单元中查找对应外部请求类型的所有诊断仪的诊断仪信息；

步骤S33：按照对应外部请求类型的所有诊断仪的诊断仪信息逐一发送诊断响应给对应的诊断仪；

步骤S34：删除请求合并记录单元中的该外部请求类型，跳转回步骤S31。