故障诊断方法、故障诊断系统、车辆和可读存储介质与流程

1.本发明涉及车辆通信技术领域，特别涉及一种故障诊断方法、故障诊断系统、车辆和可读存储介质。


背景技术：

2.相关技术中，汽车诊断故障采集都采用传统的uds方式进行对整车功能进行诊断，使用诊断设备进行对整车故障进行检测和故障数据读取，然后进行故障分析，存在故障发生很长一段时间后，才能对故障问题进行读取和数据分析，另外在诊断数据阶段存在需要多次信息认证的过程，认证过程，比较繁琐，同时带来消息认证时间过长，不能适应当前软件定义汽车的智能化需求。


技术实现要素：

3.本发明提供一种故障诊断方法、故障诊断系统、车辆和可读存储介质，以解决整车的通信硬件层和网络层、os、app层以及硬件的故障的诊断数据无法统一的采集和管理等问题。
4.本发明实施方式的一种故障诊断方法，包括：
5.获取对应的一个层框架的诊断数据，所述层框架为操作系统层、板级支持包层、硬件层、应用层的其中一个；
6.根据数据分发通信协议，对所述诊断数据进行处理以生成故障类型，所述故障类型为至少一个，所述故障类型具有对应的一个层框架；
7.将所述故障类型上报诊断服务器。
8.上述故障诊断方法，能够对不同层框架的诊断数据进行统一标准，使得不同故障可以基于数据分发通信协议对故障诊断类型进行统一整合，对外提供便利的排查和服务。
9.本发明实施方式的一种故障诊断系统，包括：
10.多个层框架，所述多个层框架包括操作系统层、板级支持包层、硬件层、应用层；
11.通信端，与所述多个层框架通信连接；
12.所述层框架用于：
13.向所述通信端发送诊断数据；
14.所述通信端用于：
15.获取所述诊断数据；
16.根据数据分发通信协议，对所述诊断数据进行处理以生成故障类型，所述故障类型对应所述层框架；
17.将所述故障类型上报诊断服务器。
18.上述故障诊断系统，能够对不同层框架的诊断数据进行统一标准，使得不同故障可以基于数据分发通信协议对故障诊断类型进行统一整合，对外提供便利的排查和服务。
19.本发明实施方式的一种车辆，包括：存储器、处理器及存储在所述存储器上并可在
所述处理器上运行的计算机程序，所述处理器执行所述程序，以实现上述实施方式所述的故障诊断方法。
20.上述车辆，能够对不同层框架的诊断数据进行统一标准，使得不同故障可以基于数据分发通信协议对故障诊断类型进行统一整合，对外提供便利的排查和服务。
21.本发明实施方式的一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行，以用于实现上述实施方式所述的故障诊断方法。
22.上述计算机可读存储介质，能够对不同层框架的诊断数据进行统一标准，使得不同故障可以基于数据分发通信协议对故障诊断类型进行统一整合，对外提供便利的排查和服务。
23.本发明附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。
附图说明
24.本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：
25.图1为根据本发明实施例提供的故障诊断方法的流程图；
26.图2-图7为根据本发明实施例的故障诊断系统的示例图；
27.图8为根据本发明实施例的数据分发服务诊断框架的示例图；
28.图9为根据本发明实施例的车辆的示例图。
29.附图标记说明：
30.故障诊断系统100；
31.层框架110、操作系统层111、板级支持包层112、硬件层113、应用层114；通信端120、
32.诊断服务器200、
33.存储器401、处理器402、通信接口403。
具体实施方式
34.在相关技术中，汽车诊断故障采集都采用传统的uds方式进行对整车功能进行诊断，使用诊断设备进行对整车故障进行检测和故障数据读取，然后进行故障分析，存在故障发生很长一段时间后，才能对故障问题进行读取和数据分析，另外在诊断数据阶段存在需要多次信息认证的过程，认证过程，比较繁琐，同时带来消息认证时间过长，不能适应当前软件定义汽车的智能化需求。
35.由于智能化、电动化、网联化的发展，汽车产业正发生着翻天覆地的变革，新功能不断增加，软件定义汽车(software define vehicle，sdv)逐渐成为共识，在汽车变革的大时代中，汽车电子电气架构(electrical/electronic architecture，eea)也正发生着变化，由于整车的功能的变化的比较快和比较复杂，随着大算力异构的soc以及大带宽数据车载以太网的出现，域控制模块和高算力计算平台出现，这些都对传统的诊断模式和诊断方案，提出了新的挑战和问题，需要有新的故障诊断方式出现，来解决高算力、高带宽、高集成度以及高安全带来新的问题。另外随着整车多os出现，目前整车soc中正在应用qnx\
android\linux等os，另外在mcu端应用rtos以及autosar cp等os，新的诊断方法也需要快速的适配多os，减少开发的工作量和降低开发成本和提升复用的效率，这些都是传统的诊断方法很难达成的效果，本发明设计采用数据分发服务的车载诊断方法，取代之前传统uds诊断方式，所以基于以上多种原因需要开发新的诊断方法来适应当前新的电子电气架构体系和新的整车开发业务的需求。
36.例如专利cn112272132b(基于fpga实现can数据的dds协议(data distribution service，数据分发服务)实时传输方法及系统)提出基于dds进行can数据射规则将can数据封装到dds数据中；通过dds协议走以太网发送到中央控制器上的dds订阅节点，处理反馈的dds数据又通过dds协议走以太网发回到域控制器。该发明(cn112272132b)主要是基于arm处理器的硬件单板上，叠加dpdk的用户态数据转发框架技术，从车载网络的底层链路上分析和诊断dds数据传输功能，但是针对当前全新中央 集成的电子电器架构和整车集成化程度越来越高和越来越复杂情况下，另外在控制器中使用不同的os，在mcu中使用autosar cp，在soc中使用android、qnx、linux和vxworks等os，这些os中的出现问题排查力度较大和较困难，在通信网络层存在以太网物理层、数据链路层、网络层、传输层以及can或者canfd的硬件物理成和数据传输层，同时硬件控制器自身的硬件故障以及依附硬件控制器的外设的故障，这些故障都需要如何诊断和诊断数据如何处理，在专利(cn112272132b)都没有涉及，需要构建一个针对整车的can、lin、os自身系统故障、以太网链路故障采集、数据传输、故障诊断自主采集和传输的诊断系统方法。另外该专利(cn112272132b)，仅仅提出一个大致的框架性思想，没有具体和进行详细发明两点，就是简单诊断服务框架。
37.最后需要对整车构建一套标准的诊断系统方法，对各个层级故障采集和传输的系统方法，既可以让故障类型自己主动上报，同时也可以被动采集故障数据，满足全新下一代“中央 区域”电子电气架构需求。
38.下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本发明，而不能理解为对本发明的限制。
39.下面参考附图描述本发明实施例的故障诊断方法、故障诊断系统、车辆和可读存储介质。针对上述背景技术中提到的汽车诊断故障采集都采用传统的uds方式进行对整车功能进行诊断，使用诊断设备进行对整车故障进行检测和故障数据读取，然后进行故障分析，存在故障发生很长一段时间后，才能对故障问题进行读取和数据分析，另外在诊断数据阶段存在需要多次信息认证的过程，认证过程，比较繁琐，同时带来消息认证时间过长，不能适应当前软件定义汽车的智能化需求的问题，本发明提供了一种故障诊断方法，在该方法中，能够对不同层框架的诊断数据进行统一标准，使得不同故障可以基于数据分发通信协议对故障诊断类型进行统一整合，对外提供便利的排查和服务。由此，解决了现有的故障诊断方法难以同时满足不同层框架的故障诊断需求等问题。
40.请参考图1和图2，本发明实施方式的一种故障诊断方法，包括：
41.01：获取对应的一个层框架的诊断数据，层框架为操作系统层、板级支持包层、硬件层、应用层的其中一个；
42.02：根据数据分发通信协议，对诊断数据进行处理以生成故障类型，故障类型为至少一个，故障类型具有对应的一个层框架；
43.03：将故障类型上报诊断服务器。
44.本发明实施方式的故障诊断方法可以通过本发明实施方式的故障诊断系统来实现。具体地，请结合图2，故障诊断系统包括多个层框架和通信端。多个层框架包括操作系统层、板级支持包层、硬件层、应用层。通信端与多个层框架通信连接。层框架用于：向通信端发送诊断数据；通信端用于：获取诊断数据；根据数据分发通信协议，对诊断数据进行处理以生成故障类型，故障类型对应层框架；将故障类型上报诊断服务器。
45.上述故障诊断方法和故障诊断系统，能够对不同层框架的诊断数据进行统一标准，使得不同故障可以基于数据分发通信协议对故障诊断类型进行统一整合，对外提供便利的排查和服务。
46.具体地，在图2中，操作系统层、板级支持包层、硬件层、应用层的任意一个在被确定存在故障的情况下，则可以根据故障生成对应的诊断数据，并将诊断数据传输给通信端以上传故障。
47.通信端在获取到诊断数据的情况下，则可以根据数据分发通信协议，对诊断数据进行处理生成故障类型。故障类型可以对应到发送诊断数据的层框架，从而可通过故障类型来对不同的层框架进行故障分类，进而实现对不同层框架的故障进行统一整合。在生成故障类型后，则可以将上报诊断服务器，使得诊断服务器能够根据故障类型进行故障排查。
48.另外，操作系统层可以为qnx、android、linux、vxworks、rtos、utosar cp。板级支持包层可以为bsp(board support package，板级支持包)。硬件层可以为以太网物理层、数据链路层、can硬件接口、canfd硬件接口、整车灯、电机、开关。应用层可以为app。
49.在某些实施方式中，故障诊断方法包括：
50.通过中断的方式获取层框架的诊断数据，或
51.通过轮询的方式获取层框架的诊断数据。
52.本发明实施方式的故障诊断方法可以通过本发明实施方式的故障诊断系统来实现。具体地，请结合图2，故障诊断系统用于：通过中断的方式获取层框架的诊断数据，或通过轮询的方式获取层框架的诊断数据。
53.如此，可实现不同的数据采集的方式。
54.具体地，在图4中，操作系统层包括诊断api(application programming interface，应用程序编程接口)、故障诊断模块和健康管理模块。在一个实施方式中，在操作系统层操作故障的情况下，可以通过健康管理模块发出中断请求使得操作系统层暂停工作程序，并通过故障诊断模块进行故障诊断，从而得到操作系统层的诊断数据，并通过诊断api向通信端传输操作系统层的诊断数据以上传故障。
55.在图5中，应用层包括应用程序日志(app log)和定制诊断sda(software define automation，软件定义自动化)。在一个实施方式中，应用层中可以包括多个应用程序。应用层可以通过app log来依序询问每一个应用程序是否需要进行故障诊断服务，并在确认需要进行故障诊断服务的情况下，对相应的应用程序进行故障诊断。在完成故障诊断服务后，则会再次依序询问其他的应用程序。
56.另外，硬件层的故障可以通过板级支持包层主动检测的方式进行确定。
57.在某些实施方式中，故障诊断方法包括：
58.生成至少一个故障标题；
59.将属于同一个层框架的故障类型放入同一个故障条例中，同一个故障条例包括在对应的一个故障标题中。
60.本发明实施方式的故障诊断方法可以通过本发明实施方式的故障诊断系统来实现。具体地，请结合图2，故障诊断系统用于：生成至少一个故障标题；将属于同一个层框架的故障类型放入同一个故障条例中，同一个故障条例包括在对应的一个故障标题中。
61.如此，可方便诊断服务器进行诊断。
62.其中，故障标题可以为topic，故障条例可以为method。
63.请参考图2，在某些实施方式中，硬件层包括硬件系统。故障诊断方法包括：
64.通过板级支持包层检测硬件系统是否存在故障；
65.在检测到硬件系统存在故障的情况下，通过板级支持包层发送对应硬件系统的诊断数据，或，
66.通过板级支持包层向操作系统层发送对应硬件系统的诊断数据，以使得对应硬件系统的诊断数据通过操作系统层发送。
67.本发明实施方式的故障诊断方法可以通过本发明实施方式的故障诊断系统来实现。具体地，请结合图2，故障诊断系统用于：通过板级支持包层检测硬件系统是否存在故障；在检测到硬件系统存在故障的情况下，通过板级支持包层发送对应硬件系统的诊断数据，或，通过板级支持包层向操作系统层发送对应硬件系统的诊断数据，以使得对应硬件系统的诊断数据通过操作系统层发送。
68.如此，可实现对硬件系统的故障的确定。
69.在某些实施方式中，故障诊断方法包括：
70.根据应用层的应用程序日志，对应用层进行定制诊断；
71.在诊断确定应用层存在故障的情况下，生成并发送对应应用层的诊断数据。
72.本发明实施方式的故障诊断方法可以通过本发明实施方式的故障诊断系统来实现。具体地，请结合图2，故障诊断系统用于：根据应用层的应用程序日志，对应用层进行定制诊断；在诊断确定应用层存在故障的情况下，生成并发送对应应用层的诊断数据。
73.如此，可快速确定应用层中存在的故障。
74.另外，在图6中，板级支持包层可以通过以太网驱动(ethernet driver)来检测以太网硬件的故障问题，以及通过can驱动(can driver)来检测can总线硬件的故障问题，以及通过lin驱动(lin driver)驱动来检测lin硬件的故障问题。
75.在确定存在的问题情况下，以太网驱动可以向以太网界面(ethernet interface)上传以太网硬件的故障问题，can驱动可以向can界面(can interface)上传can总线硬件的故障问题，lin驱动可以向lin路由(lin tp)上传lin总线硬件的故障问题。
76.其中，以太网硬件的故障问题可以从以太网界面通过tcp/ip协议上传到插座适配器(socket adaptor，soad)模块，并通过插座适配器模块上传给pdur(pdu router)模块，can总线硬件的故障问题可以从can tp模块上传到pdur模块，lin总线硬件的故障问题可以从lin路由上传到pdur模块。
77.在pdur模块接收到硬件层的故障问题后，则会将接收到硬件层的故障问题上传给com模块。com模块可以通过创建的运行环境(rte)上传给复杂驱动(cdd，complex device driver or complex driver)。
78.在复杂驱动可以通过数据分发服务接口(dds_api)接收硬件层的故障问题，并通过数据分发服务堆栈发送到整车的数据分发服务诊断平台中，实现诊断数据的对外服务和诊断数据共享。对于在硬件层中连接硬件系统的外设设备(如以太网、can硬件接口、canfd硬件接口、整车灯、电机、开关)而言，可以通过其各自的硬件驱动去检测是否存在故障，随后将各自的故障问题通过复杂驱动中对应的复杂驱动模块发送到数据分发服务诊断平台中，然后对外提供诊断数据服务和诊断数据共享，以便后期进行下一步使用动作。
79.另外，在图7中，软件模块(kernel and driver)的故障数据可以上传给第一日志模块。第一日志模块在接收到故障后可以再上传给第二日志模块，并可以通过数据分发服务堆栈来请求外部的诊断服务。在第二日志模块收集到软件模块的故障数据后，应用程序日志可以将故障数据发送给第二日志模块，或者直接发送给定制诊断sda，然后再发送给数据分发服务堆栈，最终请求外部的诊断服务。
80.在图8中，通信端内部具有数据分发服务诊断框架。诊断数据可以根据不同的诊断数据类型，映射到不同的故障标题中。在同一类型的诊断数据中，可以在映射到同一个故障标题的不同的故障条例内，最终通过诊断数据请求外部的诊断服务的时候，诊断服务器可以根据数据分发服务协议栈进行诊断数据的解析，实现对诊断数据的应用。
81.在某些实施方式中，硬件层包括硬件系统和外设设备。外设设备通信连接硬件系统。具体地，硬件系统可以包括
82.另外，外设设备可以包括以太网、can硬件接口、canfd硬件接口、整车灯、电机、开关。
83.综上所述，本发明的实施方式主要分为三点：
84.第一点：对整车硬件和系统本身的软件故障，进行采集和上报；
85.第二点：数据采集的方式，既可以采用中断方式，也可以采用轮询的方式进行诊断数据访问和采集以及上报；
86.第三点：采用dds通信中间件，对诊断故障数据进行统一采集和故障数据命名以及对外提供诊断服务。
87.针对第一点，就是构建对整车硬件和软件一体化的诊断框架，将整车中不同的故障类型，通过dds中间件进行统一，并对外提供诊断服务，对于硬件以及其外设故障通过bsp采用主动检测的方式，检测到硬件故障或者是外设的故障后，进行故障数据上传到dds通信中间件，然后诊断数据在dds通信中间件放入预定的topic中，提供对外诊断服务。同样的系统内部(os或者app)出现故障的时候，也会将数据上传到dds中间件中的topic中，然后对外提供诊断服务。
88.发明第二点，硬件系统故障或者是软件系统故障，既可以通过中断方式去检测故障并上报诊断数据，也可以轮询的方式去检测故障和数据上报。
89.发明第三点：在dds中间件中，定义一个故障topic(标题)，或者是根据不同的诊断故障类型，定义不同的topic，可以是topic1、topic2......topicn，然后在把同一类型的故障放到该topic下method中，提供对外的诊断服务。
90.也就是说，本发明的目的是在解决整车的通信硬件层和网络层、os、app层以及硬件的故障的诊断数据无法统一的采集和管理的问题，由于各层之间没有统一的诊断接口和诊断协议，去统筹管理硬件和系统内部的故障，所以构建一个基于dds通信中间件的诊断系
统方法，把各个层级的诊断进行整合，统一对外提供标准的诊断数据。各个层级构建统一的诊断接口进行数据采集和上报，在dds中间件给各个诊断的数据，进行统一命名，提供诊断的topic name对外提供诊断数据服务，在topic name下的method进行规划各种具体的诊断故障类型。这些故障都可以基于dds协议对故障诊断类型进行统一整合，对外提供便利的排查和服务。
91.图9为本发明实施例提供的车辆的结构示意图。该车辆可以包括：
92.存储器401、处理器402及存储在存储器401上并可在处理器402上运行的计算机程序。
93.处理器402执行程序时实现上述实施例中提供的控制方法。
94.进一步地，车辆还包括：
95.通信接口403，用于存储器401和处理器402之间的通信。
96.存储器401，用于存放可在处理器402上运行的计算机程序。
97.存储器401可能包含高速ram(random access memory，随机存取存储器)存储器，也可能还包括非易失性存储器，例如至少一个磁盘存储器。
98.如果存储器401、处理器402和通信接口403独立实现，则通信接口403、存储器401和处理器402可以通过总线相互连接并完成相互间的通信。总线可以是isa(industry standard architecture，工业标准体系结构)总线、pci(peripheral component，外部设备互连)总线或eisa(extended industry standard architecture，扩展工业标准体系结构)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图9中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
99.可选的，在具体实现上，如果存储器401、处理器402及通信接口403，集成在一块芯片上实现，则存储器401、处理器402及通信接口403可以通过内部接口完成相互间的通信。
100.处理器402可能是一个cpu(central processing unit，中央处理器)，或者是asic(application specific integrated circuit，特定集成电路)，或者是被配置成实施本发明实施例的一个或多个集成电路。
101.本发明实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上的控制方法。
102.在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不是必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或n个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
103.此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中，“n个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。
104.流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括
一个或更n个用于实现定制逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本发明的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本发明的实施例所属技术领域的技术人员所理解。
105.应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，n个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。如，如果用硬件来实现和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列，现场可编程门阵列等。
106.本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。
107.尽管上面已经示出和描述了本发明的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。