CN107154085A - 车载诊断数据的处理方法及处理装置 - Google Patents

Abstract

本发明公开了一种车载诊断数据的处理方法，上述处理方法包括：当车辆的车载操作系统启动时，创建车载诊断任务；在所述车载诊断任务的指示下，实时获取所述车辆的车载诊断数据；当所述车载诊断任务注销时，停止获取所述车辆的车载诊断数据。本发明还提供相应的处理装置。通过本发明方案，能够有效提高车载诊断数据获取的灵活性。

Description

车载诊断数据的处理方法及处理装置

技术领域

本发明涉及车辆技术领域，具体涉及一种车载诊断数据的处理方法及处理装置。

背景技术

车载诊断(OBD，On-Board Diagnostic)系统是可随时监控发动机的运行状态和尾气处理系统工作状态的一个车载终端，OBD数据包括对发动机、催化转化器、颗粒捕集器、氧传感器、排放控制系统、燃油系统、排气再循环(EGR，Exhaust Gas Recirculation)等进行监控时取得的车载诊断数据。

现有的OBD系统是由裸机程序编写，因此，只要OBD接口通电，OBD接口便会在裸机程序的控制下获取OBD数据。由于目前OBD接口是通过常电供电(常电是指从车辆的电瓶正极接出来不受任何开关,继电器等控制的正电源)，因此，即使车辆熄火了，OBD接口也将处于通电状态，此时在裸机程序的控制下会继续通过OBD接口获取OBD数据，从而造成不必要的功耗浪费。如果想要停止OBD数据的获取，只能断开OBD接口的供电线路，但是普通用户压根都不知道如何断开OBD接口的供电线路。

发明内容

本发明提供一种车载诊断数据的处理方法及处理装置，用于提高车载诊断数据获取的灵活性。

本发明第一方面提供一种车载诊断数据的处理方法，该处理方法包括：

当车辆的车载操作系统启动时，创建车载诊断任务；

在所述车载诊断任务的指示下，实时获取所述车辆的车载诊断数据；

当所述车载诊断任务注销时，停止获取所述车辆的车载诊断数据。

基于本发明第一方面，在第一种可能的实现方式中，所述创建车载诊断任务，之后包括：

当所述车辆熄火或者退出所述车辆的车载操作系统时，注销所述车载诊断任务。

基于本发明第一方面或者本发明第一方面的第一种可能的实现方式，在第二种可能的实现方式中，若所述车辆的车载操作系统为首次启动，则在所述实时获取所述车辆的车载诊断数据之前，所述处理方法还包括：确定所述车辆的诊断总线类型；

所述实时获取所述车辆的车载诊断数据为：根据已确定的所述车辆的诊断总线类型，采用相应的通讯协议实时获取所述车辆的车载诊断数据。

基于本发明第一方面或者本发明第一方面的第一种可能的实现方式，在第三种可能的实现方式中，所述实时获取所述车辆的车载诊断数据，之前还包括：

在所述车载诊断任务的指示下，调用预设的接口函数进入所述车辆的车载自动诊断系统；

所述实时获取所述车辆的车载诊断数据为：基于所述车辆的车载自动诊断系统，实时获取所述车辆的车载诊断数据。

基于本发明第一方面的第三种可能的实现方式，在第四种可能的实现方式中，所述车载自动诊断系统为OBD系统；

所述在所述车载诊断任务的指示下，调用预设的接口函数进入所述车辆的车载自动诊断系统为：

在所述车载诊断任务的指示下，调用OBDIIEnter()接口函数进入所述车辆的OBD系统。

本发明第二方面提供一种车载诊断数据的处理装置，该处理装置包括：

任务创建单元，用于当车辆的车载操作系统启动时，创建车载诊断任务；

获取单元，用于在所述车载诊断任务的指示下，实时获取所述车辆的车载诊断数据；并当所述车载诊断任务注销时，停止获取所述车辆的车载诊断数据。

基于本发明第二方面，在第一种可能的实现方式中，所述处理装置还包括：

注销单元，用于当所述车辆熄火或者退出所述车辆的车载操作系统时，注销所述车载诊断任务。

基于本发明第二方面或者本发明第二方面的第一种可能的实现方式，在第二种可能的实现方式中，所述处理装置还包括：

确定单元，用于当所述车辆的车载操作系统为首次启动时，确定所述车辆的诊断总线类型；

所述获取单元具体用于：根据所述确定单元已确定的所述车辆的诊断总线类型，采用相应的通讯协议实时获取所述车辆的车载诊断数据。

基于本发明第二方面，或者本发明第二方面的第一种可能的实现方式，在第三种可能的实现方式中，所述处理装置还包括：

车载自动诊断系统运行单元，用于在所述车载诊断任务的指示下，调用预设的接口函数进入所述车辆的车载自动诊断系统；

所述获取单元具体用于：基于所述车辆的车载自动诊断系统，实时获取所述车辆的车载诊断数据。

基于本发明第二方面的第三种可能的实现方式，在第四种可能的实现方式中，所述车载自动诊断系统为OBD系统；

所述车载自动诊断系统运行单元具体用于：在所述车载诊断任务的指示下，调用OBDIIEnter()接口函数进入所述车辆的OBD系统。

由上可见，本发明方案基于车载诊断任务实时获取车辆的车载诊断数据，并在车载诊断任务注销时，停止获取该车辆的车载诊断数据。通过车载操作系统的任务形式控制车载诊断数据的获取，一方面使得车载诊断数据的获取方式更为灵活，另一方面在车辆熄火后可以通过注销车载诊断任务的方式停止车载诊断数据的获取，减少不必要的功耗浪费。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明提供的车载诊断数据的处理方法一个实施例流程示意图；

图2为本发明提供的车载诊断数据的处理装置一个实施例结构示意图；

图3为本发明提供的车载诊断数据的处理装置一个实施例结构示意图。

具体实施方式

为使得本发明的发明目的、特征、优点能够更加的明显和易懂，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而非全部实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

实施例一

本发明实施例对一种车载诊断数据的处理方法进行描述，请参阅图1，本发明实施例中的处理方法包括：

步骤101，当车辆的车载操作系统启动时，创建车载诊断任务；

本发明实施例中，车载操作系统是指集成在车辆上的操作系统。本发明实施例中的车载操作系统可以包括但不限于：实时操作系统(RTX，Real-Time eXtension)、FreeRTOS操作系统、uCos操作系统。

在步骤101中，当车辆的车载操作系统启动时，创建车载诊断任务。本发明实施例中，针对不同类型的车载操作系统，可以设置相应的方式创建车载诊断任务。以操作系统为RTX为例，上述创建车载诊断任务具体可以为：调用os_tsk_create_user(tsk，prio,stk,size)函数创建车载诊断任务。其中，上述函数中的第1个参数tsk指示所创建任务的函数名；第2个参数prio指示所创建任务的优先级，用户可以设置的任务优先级范围是1-254，优先级0用于空闲任务，优先级255被保留用于更重要的任务，如果新创建的任务的优先级比当前正在执行的任务的优先级高，那么就会立即切换到高优先级任务去执行；第3个参数stk指示任务栈地址；第4个参数size指示任务栈大小。

步骤102，在上述车载诊断任务的指示下，实时获取上述车辆的车载诊断数据；

本发明实施例中，车载诊断数据是指与车辆相关的数据，例如：车辆运行速度、发动机转速、发动机温度、水箱温度、运行里程、车灯状态、运行时长、档位、安全带状态、车门状态,实时的故障信息等。上述实时获取上述车辆的车载诊断数据为基于诊断总线(例如控制器局域网络(CAN，Controller Area Network)总线、K线(即KAP总线)或LIN线)实时获取上述车辆的车载诊断数据，具体的，实时获取车载诊断数据的过程可以参照已有技术实现，此处不再赘述。

由于不同的诊断总线类型所采用的通讯协议有所不同，因此，本发明实施例可以预先设置与各种诊断总线类型相应的通讯协议，以适应不同的车辆。可选的，若上述车辆的车载操作系统为首次启动，则在上述实时获取上述车辆的车载诊断数据之前，本发明实施例中的处理方法还包括：确定上述车辆的诊断总线类型；上述实时获取所述车辆的车载诊断数据为：根据已确定的上述车辆的诊断总线类型，采用相应的通讯协议实时获取上述车辆的车载诊断数据。需要说明的是，由于车辆的诊断总线类型一般不会改变，因此，在确定上述车辆的诊断总线类型之后，后续当车载操作系统再次启动时(例如上述车载操作系统在车辆再次发动时启动的情况下)，可以不需要再次确定上述车辆的诊断总线类型，而直接基于之前已确定的上述车辆的诊断总线类型，采用相应的通讯协议实时获取上述车辆的车载诊断数据。

可选的，在上述实时获取上述车辆的车载诊断数据之前，本发明实施例还包括：在步骤101创建的车载诊断任务的指示下，调用预设的接口函数进入上述车辆的车载自动诊断系统。上述实时获取上述车辆的车载诊断数据，具体为：基于上述车辆的车载自动诊断系统实时获取上述车辆的车载诊断数据。以车载自动诊断系统为OBD系统为例进行说明，在步骤101创建的车载诊断任务的指示下，调用预设的接口函数(例如OBDIIEnter())进入上述车辆的车载自动诊断系统，在进入OBD系统之后，基于诊断总线类型，采用相应的通讯协议实时获取上述车辆的车载诊断数据。例如，进入OBD系统之后，可以以u32OBDIIReadData(u8PID)类型接口函数实时获取上述车辆的车载诊断数据，其中，参数PID可以为一个数组的形式，以循环查询并获取车辆的各个动态数据，如:设置PID 0x0C查询并获取车辆实时的转速、PID 0x0D查询并车辆实时的车速等。

当然，本发明实施例中，也可以不基于上述车辆的车载自动诊断系统实时获取上述车辆的车载诊断数据，而直接与车辆的各个控制模块(例如发动机控制模块、悬架控制模块、牵引力控制模块、故障诊断控制模块等)进行实时通讯，获取上述车辆的车载诊断数据，此处不作限定。

步骤103，当上述车载诊断任务注销时，停止获取上述车辆的车载诊断数据；

可选的，当上述车辆熄火或者退出上述车辆的车载操作系统时，注销上述车载诊断任务，以停止获取上述车辆的车载诊断数据，从而达到释放内存资源、节省功耗的目的。具体的，可以调用os_tsk_delete(task_id)函数注销上述车载诊断任务，其中，参数task_id为该车载诊断任务的id号。

当然，本发明实施例中，也可以设置在其它条件下，注销上述车载诊断任务，例如可以设置一按键，当检测到该按键触发时，注销上述车载诊断任务，当检测到该按键再次触发时，重新创建上述车载诊断任务，以重新触发步骤102以及后续步骤的执行。

需要说明的是，本发明实施例中的处理方法可以由相应的处理装置实现，该处理装置具体可以基于STM32芯片和RTX操作系统构建，当然，该STM32芯片也可以替换为Freescale或其它处理芯片，该RTX操作系统也可以替换为FreeRTOS操作系统、uCos操作系统或其它类型的操作系统，此处不作限定。

由上可见，本发明实施例中的处理方法基于车载诊断任务实时获取车辆的车载诊断数据，并在车载诊断任务注销时，停止获取该车辆的车载诊断数据。通过车载操作系统的任务形式控制车载诊断数据的获取，一方面使得车载诊断数据的获取方式更为灵活，另一方面在车辆熄火后可以通过注销车载诊断任务的方式停止车载诊断数据的获取，减少不必要的功耗浪费。

实施例二

本发明实施例中对一种车载诊断数据的处理装置进行描述，请参阅图2，本发明实施例中的处理装置200包括：

任务创建单元201，用于当车辆的车载操作系统启动时，创建车载诊断任务；

获取单元202，用于在所述车载诊断任务的指示下，实时获取所述车辆的车载诊断数据；并当所述车载诊断任务注销时，停止获取所述车辆的车载诊断数据。

可选的，在图2所示的处理装置基础上，如图3所示，本发明实施例中的处理装置300还包括：

注销单元203，用于当所述车辆熄火或者退出所述车辆的车载操作系统时，注销所述车载诊断任务。

可选的，在图1或图2所示的处理装置基础上，本发明实施例中的处理装置还包括：确定单元，用于当所述车辆的车载操作系统为首次启动时，确定所述车辆的诊断总线类型；获取单元202具体用于：根据所述确定单元已确定的所述车辆的诊断总线，采用相应的通讯协议实时获取所述车辆的车载诊断数据。

可选的，本发明实施例中的处理装置还包括：

车载自动诊断系统运行单元，用于在所述车载诊断任务的指示下，调用预设的接口函数进入所述车辆的车载自动诊断系统；

获取单元202具体用于：基于所述车辆的车载自动诊断系统，实时获取所述车辆的车载诊断数据。

可选的，所述车载自动诊断系统为OBD系统；所述车载自动诊断系统运行单元具体用于：在所述车载诊断任务的指示下，调用OBDIIEnter()接口函数进入所述车辆的OBD系统。

需要说明的是，本发明实施例中的处理装置具体可以基于STM32芯片和RTX操作系统构建，当然，该STM32芯片也可以替换为Freescale或其它处理芯片，该RTX操作系统也可以替换为FreeRTOS操作系统、uCos操作系统或其它类型的操作系统，此处不作限定。

应理解，本发明实施例中的处理装置可以用于实现上述方法实施例中的全部技术方案，其各个功能模块的功能可以根据上述方法实施例中的方法具体实现，其具体实现过程可参照上述实施例中的相关描述，并且，在本发明实施例中没有详述和提及的部分，可以参见上述方法实施例的描述，此处不再赘述。

由上可见，本发明实施例中的处理装置基于车载诊断任务实时获取车辆的车载诊断数据，并在车载诊断任务注销时，停止获取该车辆的车载诊断数据。通过车载操作系统的任务形式控制车载诊断数据的获取，一方面使得车载诊断数据的获取方式更为灵活，另一方面在车辆熄火后可以通过注销车载诊断任务的方式停止车载诊断数据的获取，减少不必要的功耗浪费。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将上述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

在本发明所提供的实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的系统实施例仅仅是示意性的，例如，上述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。

上述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

以上所述实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围，均应包含在本发明的保护范围之内。

Claims (10)

1.一种车载诊断数据的处理方法，其特征在于，所述处理方法包括：

当车辆的车载操作系统启动时，创建车载诊断任务；

在所述车载诊断任务的指示下，实时获取所述车辆的车载诊断数据；

当所述车载诊断任务注销时，停止获取所述车辆的车载诊断数据。

2.根据权利要求1所述的处理方法，其特征在于，所述创建车载诊断任务，之后包括：

当所述车辆熄火或者退出所述车辆的车载操作系统时，注销所述车载诊断任务。

3.根据权利要求1或2所述的处理方法，其特征在于，若所述车辆的车载操作系统为首次启动，则在所述实时获取所述车辆的车载诊断数据之前，所述处理方法还包括：确定所述车辆的诊断总线类型；

所述实时获取所述车辆的车载诊断数据为：根据已确定的所述车辆的诊断总线类型，采用相应的通讯协议实时获取所述车辆的车载诊断数据。

4.根据权利要求1或2所述的处理方法，其特征在于，所述实时获取所述车辆的车载诊断数据，之前还包括：

在所述车载诊断任务的指示下，调用预设的接口函数进入所述车辆的车载自动诊断系统；

所述实时获取所述车辆的车载诊断数据，为：

基于所述车辆的车载自动诊断系统，实时获取所述车辆的车载诊断数据。

5.根据权利要求4所述的处理方法，其特征在于，所述车载自动诊断系统为OBD系统；

所述在所述车载诊断任务的指示下，调用预设的接口函数进入所述车辆的车载自动诊断系统为：

在所述车载诊断任务的指示下，调用OBDIIEnter()接口函数进入所述车辆的OBD系统。

6.一种车载诊断数据的处理装置，其特征在于，所述处理装置包括：

任务创建单元，用于当车辆的车载操作系统启动时，创建车载诊断任务；

获取单元，用于在所述车载诊断任务的指示下，实时获取所述车辆的车载诊断数据；并当所述车载诊断任务注销时，停止获取所述车辆的车载诊断数据。

7.根据权利要求6所述的处理装置，其特征在于，所述处理装置还包括：

注销单元，用于当所述车辆熄火或者退出所述车辆的车载操作系统时，注销所述车载诊断任务。

8.根据权利要求6或7所述的处理装置，其特征在于，所述处理装置还包括：

确定单元，用于当所述车辆的车载操作系统为首次启动时，确定所述车辆的诊断总线类型；

所述获取单元具体用于：根据所述确定单元已确定的所述车辆的诊断总线，采用相应的通讯协议实时获取所述车辆的车载诊断数据。

9.根据权利要求6或7所述的处理装置，其特征在于，所述处理装置还包括：

车载自动诊断系统运行单元，用于在所述车载诊断任务的指示下，调用预设的接口函数进入所述车辆的车载自动诊断系统；

所述获取单元具体用于：基于所述车辆的车载自动诊断系统，实时获取所述车辆的车载诊断数据。

10.根据权利要求9所述的处理装置，其特征在于，所述车载自动诊断系统为OBD系统；

所述车载自动诊断系统运行单元具体用于：在所述车载诊断任务的指示下，调用OBDIIEnter()接口函数进入所述车辆的OBD系统。