诊断方法、车辆、系统及存储介质与流程

1.本申请涉及车辆控制技术领域，尤其涉及一种诊断方法、车辆、系统及存储介质。


背景技术：

2.车辆诊断是对车辆的各部件进行诊断，以确定车辆的故障部位、故障原因或各部件的运行状态。目前，车辆的诊断方法基本为车辆逐条接收服务器发送的诊断命令，并依次根据诊断命令执行诊断。由于诊断命令的传输和执行严重依赖网络的传输稳定性，因此，现有诊断方法存在因网络传输稳定性差而导致诊断稳定性差和效率低的问题。


技术实现要素：

3.本申请实施例提供一种诊断方法、车辆、系统及存储介质，以解决相关技术存在的问题，技术方案如下：
4.第一方面，本申请实施例提供了一种车辆，包括：
5.设备管理单元，用于接收诊断脚本；
6.诊断解析单元，用于对诊断脚本进行解析，得到该诊断脚本所包含的至少一条诊断指令；
7.诊断单元，用于基于诊断脚本所包含的至少一条诊断指令对目标电子控制单元ecu执行诊断，并得到该目标ecu对应的诊断结果。
8.第二方面，本申请实施例提供了一种诊断方法，应用于车辆，包括：
9.该车辆的设备管理单元接收诊断脚本；
10.该车辆的诊断解析单元对诊断脚本进行解析，得到该诊断脚本所包含的至少一条诊断指令；
11.该车辆的诊断单元基于诊断脚本所包含的至少一条诊断指令对目标电子控制单元ecu执行诊断，并得到该目标ecu对应的诊断结果。
12.第三方面，本申请实施例提供了一种诊断系统，包括：
13.服务器，用于向车辆发送诊断脚本；
14.车辆，用于接收诊断脚本；对所述诊断脚本进行解析，得到所述诊断脚本所包含的至少一条诊断指令；基于所述诊断脚本所包含的所述至少一条诊断指令，对目标电子控制单元ecu执行诊断，得到所述目标ecu对应的诊断结果。
15.第四方面，本申请实施例提供了一种车辆，包括：
16.至少一个处理器；以及
17.与该至少一个处理器通信连接的存储器；其中，
18.该存储器存储有可被该至少一个处理器执行的指令，该指令被该至少一个处理器执行，以使该至少一个处理器能够上述第二方面中任一种实施方式的方法。
19.第五方面，本申请实施例提供了一种存储有计算机指令的非瞬时计算机可读存储介质，计算机可读存储介质存储计算机指令，当计算机指令在计算机上运行时，上述各方面
任一种实施方式中的方法被执行。
20.上述技术方案中的优点或有益效果至少包括：通过车辆的设备管理单元接收包含一条或多条诊断指令的诊断脚本，有利于提高诊断指令的接收效率，避免因网络中断而导致诊断指令的接收中断，可提高对诊断指令进行接收的稳定性；并且，诊断解析单元对诊断脚本的解析过程在车辆端进行，以及诊断单元可直接基于解析后的诊断指令对目标ecu执行诊断，因此，能够有效提高诊断执行的稳定性。
21.上述概述仅仅是为了说明书的目的，并不意图以任何方式进行限制。除上述描述的示意性的方面、实施方式和特征之外，通过参考附图和以下的详细描述，本申请进一步的方面、实施方式和特征将会是容易明白的。
附图说明
22.在附图中，除非另外规定，否则贯穿多个附图相同的附图标记表示相同或相似的部件或元素。这些附图不一定是按照比例绘制的。应该理解，这些附图仅描绘了根据本申请公开的一些实施方式，而不应将其视为是对本申请范围的限制。
23.图1为根据本申请实施例的车辆的结构示意图一；
24.图2为根据本申请实施例的车辆的结构示意图二；
25.图3为根据本申请实施例的车辆的结构示意图三；
26.图4为根据本申请实施例的车辆的结构示意图四；
27.图5为根据本申请实施例的车辆的结构示意图五；
28.图6为根据本申请实施例的车辆的结构示意图六；
29.图7为根据本申请实施例的诊断方法的流程示意图一；
30.图8为根据本申请实施例的诊断方法的流程示意图二；
31.图9为根据本申请实施例的诊断方法的流程示意图三；
32.图10为根据本申请实施例的诊断方法的流程示意图四；
33.图11为根据本申请实施例的诊断方法的流程示意图五；
34.图12为根据本申请实施例的车辆中各个单元的一种交互流程示意图；
35.图13a为根据本申请实施例的诊断系统的结构示意图；
36.图13b为根据本申请实施例的诊断系统中各个装置的交互流程示意图；
37.图14是用来实现本申请实施例的诊断方法的车辆的框图。
具体实施方式
38.在下文中，仅简单地描述了某些示例性实施例。正如本领域技术人员可认识到的那样，在不脱离本申请的精神或范围的情况下，可通过各种不同方式修改所描述的实施例。因此，附图和描述被认为本质上是示例性的而非限制性的。
39.图1示出根据本申请实施例的车辆的结构示意图一。如图1所示，该车辆100可以包括：
40.设备管理单元110，用于接收诊断脚本；
41.诊断解析单元120，用于对所述诊断脚本进行解析，得到所述诊断脚本所包含的至少一条诊断指令；
42.诊断单元130，用于基于所述诊断脚本所包含的所述至少一条诊断指令对目标ecu140(electronic control unit，电子控制单元)执行诊断，并得到目标ecu140对应的诊断结果。
43.其中，所述诊断脚本可以包含一条诊断指令，也可以包含多条诊断指令。
44.所述诊断脚本与目标ecu140之间具备对应关系，其中，目标ecu140可以是车辆100的各个ecu中任意之一，各个ecu可以包括车身域控制器、网关、信息娱乐域控制器、电动助力转向控制系统、安全气囊控制器等，在此不做具体限制。也就是说，诊断脚本可以是以ecu为单位，不同的诊断脚本可以对应不同的ecu，当然，不同的诊断脚本也可以针对同一个ecu，根据实际情况来确定，这里不做穷举。
45.例如，诊断脚本a可以包含第一目标ecu的一条或多条诊断指令，诊断脚本b可以包含第二目标ecu的一条或多条诊断指令。
46.在一个示例中，当设备管理单元110接收到诊断脚本a时，可以将该诊断脚本a传给所述诊断解析单元120；所述诊断解析单元120对诊断脚本a进行解析，得到第一目标ecu对应的一条或多条诊断指令；所述诊断解析单元120将针对所述第一目标ecu的一条或多条指令发送给诊断单元130；进而诊断单元130对第一目标ecu执行与该一条或多条诊断指令，最终得到第一目标ecu对应的诊断结果。这里，诊断单元130执行一条或多条诊断指令的时候，可以依次接收到针对每一条诊断指令所对应的子诊断结果，诊断单元130可以在接收到全部诊断指令所对应的子诊断结果之后，汇总得到总的诊断结果。如此，有利于对指定的目标ecu执行指定诊断，便于完成整个诊断任务流程。
47.需要指出的是，车辆的设备管理单元110接收到的诊断脚本可以包括一个或多个；在接收到多个诊断脚本的情况下，设备管理单元110可以依次将诊断脚本发送给诊断解析单元120，相应的，诊断解析单元120可依次对诊断脚本进行解析，诊断单元130可依次对目标ecu140执行诊断。
48.例如，当设备管理单元110依次接收到诊断脚本a和诊断脚本b时，则诊断解析单元120依次对诊断脚本a和诊断脚本b进行解析，诊断单元130依次对第一目标ecu和第二目标ecu执行诊断；其中，第一目标ecu和第二目标ecu可以相同，也可以不同。
49.根据本申请实施例的车辆100，通过车辆100的设备管理单元110接收包含一条或多条诊断指令的诊断脚本，有利于提高诊断指令的接收效率，避免因网络中断而导致诊断指令的接收中断，可提高对诊断指令进行接收的稳定性；并且，诊断解析单元120对诊断脚本的解析过程在车辆端进行，以及诊断单元130可直接基于解析后的诊断指令对目标ecu140执行诊断，因此，能够有效提高远程诊断的稳定性。
50.在一种实施方式中，设备管理单元110还可以用于接收与诊断脚本相对应的诊断策略；基于所述诊断策略确定所述诊断脚本的执行时间；在到达所述执行时间的情况下，向诊断解析单元120发送对应的诊断脚本，以使诊断解析单元120解析诊断脚本，进而诊断单元130执行诊断。
51.需要说明的时，在设备管理单元110未接收到与诊断脚本相对应的诊断策略的情况下，则设备管理单元110可以在接收到诊断脚本后直接向诊断解析单元120实时提供诊断脚本，使得诊断单元130实时执行诊断。如此，便于根据诊断需求，灵活调整诊断的执行，改善诊断的时效性。
52.本发明的又一实施例中，车辆中的设备管理单元，可以将其称为设备管理客户端(device management client)，还可以与云端的服务器建立连接，进而可以从云端的服务器获取到诊断脚本。
53.相应的，所述设备管理单元110，用于通过与服务器之间的连接，从服务器获取诊断脚本和诊断脚本的配置文件，配置文件包含诊断脚本对应的诊断参数。
54.关于诊断脚本在云端的生成方式，可以包括：诊断脚本可以采用诊断序列配置工具自动生成，或者，也可以采用编程工具编写得到。诊断脚本的生成方式以根据实际需要进行选择和调整，本申请实施例对诊断脚本的生成方式不作限制。
55.其中，诊断序列配置工具或编程工具可以安装在云端的所述服务器上，这样诊断脚本可直接在服务器上生成；诊断序列配置工具或编程工具还可以安装在计算机上，这样诊断脚本可在计算机生成，并由计算机上传至云端的服务器。
56.所述诊断脚本的配置文件，可以是所述诊断脚本的manifest文件。所述诊断脚本的所述配置文件可基于在服务器上对诊断脚本的配置操作生成，其中，配置文件可以包括诊断脚本与诊断任务之间的对应关系。例如，诊断脚本可包含id(identity document)标识，诊断任务与诊断脚本的id标志之间具有一一对应关系或一对多的对应关系。如此，便于完成整个诊断任务流程，提高诊断效率。
57.所述诊断脚本的配置文件中可以包括执行诊断脚本时所需的诊断参数，诊断解析单元120可对诊断脚本进行解析，以得到一条或多条诊断指令；诊断单元130将诊断参数通过诊断指令写入到目标ecu中。例如，诊断脚本为钥匙匹配，诊断参数为pn(pseudo
‑
noise code)码和车辆防盗sk码，则诊断解析单元120解析得到的诊断指令将pn码和sk码写入到bdcm(body domain control module，车身域控制器)控制器中，并触发bdcm控制器匹配指定的钥匙。
58.针对目标ecu140执行诊断所得到的所述诊断结果可以通过远程终端设备上传至云端的所述服务器的。
59.在一个示例中，如图2所示，设备管理单元110可以与服务器建立通信连接。所述设备管理单元110与服务器之间的通信方式可以为wifi、4g和5g等，本申请对此不作限制。如此，有利于将车辆100与服务器进行通信连接，进行车辆100的下线诊断。
60.设备管理单元110可以采用payload数据传输方式从服务器获取与所述车辆的vin(车辆识别码，vehicle identification number)所对应的诊断脚本及其配置文件，其中配置文件包含诊断脚本的诊断参数；进一步地，与所述车辆的vin(车辆识别码，vehicle identification number)所对应的诊断脚本及其配置文件和诊断参数可以作为payload(有效载荷)通过设备管理单元110与所述服务器之间的连接进行传输。
61.在一个示例中，服务器可以包括：身份管理单元，用于对登录服务器的指定设备进行身份验证和权限管理。
62.例如，当采用车辆诊断仪、平板电脑、移动终端等设备登录服务器时，则需要对这类设备的身份信息进行验证，并在身份信息验证通过的情况下，才允许登录。此外，服务器还可以对这类设备配置适应等级的权限。
63.基于此，可以提高服务器访问的安全性，进而提高诊断的安全性，避免对车辆100进行非法诊断。
64.在前述图1或图2的基础上，本发明的又一实施例中如图3所示，车辆100还可以包括：
65.下载单元310，用于从设备管理单元110获取诊断脚本，对诊断脚本进行验证；在诊断脚本验证通过的情况下，将诊断脚本和诊断脚本的配置文件(含诊断参数)保存至文件传输单元320；
66.文件传输单元320，用于保存诊断脚本和诊断脚本的配置文件(含诊断脚本对应的诊断参数)。
67.这里，所述文件传输单元320或者还可以称为ftp(file transfer protocol，文件传输协议)服务单元。
68.在一个示例中，下载单元310还用于对诊断脚本进行解析转换，得到诊断脚本的压缩文件，并在诊断脚本验证通过的情况下，将诊断脚本的压缩文件、配置文件和诊断参数保存至文件传输单元320。
69.其中，下载单元310对所述诊断脚本进行验证，可以包括有完整性校验、有效性校验等等，比如，可以检测诊断脚本的时间是否在有效期内，或者，诊断脚本的版本是否正确等，当然，还可以包括其他的验证方式，均可以在本实施例的保护范围内，只是不对其进行穷举。
70.在本实施方式中，通过下载单元310对诊断脚本进行验证，并在验证通过的情况下将诊断脚本及其配置文件保存至文件传输单元320，以便诊断单元130进行下载，有利于提高诊断的准确性，避免不符合要求的诊断脚本参与执行。并且，下载单元310可将诊断脚本解析转换成诊断脚本的压缩文件，还可以节省文件传输单元320的存储空间；此外，文件传输单元320对诊断脚本相关的数据进行集中存储，还便于提高后续执行诊断过程中数据的传输和处理效率，进而提高诊断效率。
71.在一种实施方式中，如图4所示，车辆100还可以包括：分发单元410，用于获取诊断脚本的配置文件，对诊断脚本的配置文件进行解析得到诊断任务；以及从文件传输单元320获取诊断任务对应的诊断脚本。
72.在一个示例中，诊断脚本的配置文件可以包括诊断任务，并且诊断任务的标识或id可以与诊断脚本的id具备对应关系，或者诊断任务中可以包含有诊断脚本的标识(或称为id)。分发单元410通过对诊断脚本的配置文件进行解析得到诊断任务，进而可以基于诊断任务得知本次诊断任务所对应的诊断脚本，然后分发单元410可从文件传输单元320准确获取与诊断任务匹配的诊断脚本，进而分发单元410向诊断解析单元120发送对应的诊断脚本，以使得诊断解析单元120对该诊断脚本进行解析，有利于提高诊断脚本的传输效率和解析效率，可节省运算资源和提高诊断执行的准确性。
73.其中，分发单元410还用于检查车况；在车况满足一定条件的情况下，向诊断单元130发送诊断指令，如此可以进一步提高执行诊断的安全性。这里，所述分发单元410检查车况可以是检查车辆是否可以进行诊断，比如是否正在行驶状态中，或者是否全车上电等等，相应的，若当前车辆处于行驶状态，则可以为不满足条件，则不进行诊断指令的发送。具体的检查内容以及对应的条件可以根据实际情况进行设置，这里不做穷举。
74.在一种实施方式中，诊断单元130，还用于将目标ecu140对应的诊断结果发送至文件传输单元320；相应的，下载单元310，还用于从文件传输单元320获取针对目标ecu140对
应的诊断结果。
75.在一个示例中，诊断单元130可通过分发单元410将目标ecu140对应的诊断结果发送至文件传输单元320进行保存，并向下载单元310发送保存成功指令。相应的，下载单元310可以根据保存成功指令，从文件传输单元320获取针对目标ecu140对应的诊断结果，以便传输至设备管理单元110。
76.在本实施方式中，诊断单元130将诊断结果发送至文件传输单元320进行保存，可便于对诊断结果进行集中保存，提高储存资源的利用效率，也可以防止诊断结果丢失；并且，便于将诊断单元130的执行诊断过程与下载单元310的诊断结果下载和转发过程进行分离，提高诊断效率。
77.在一种实施方式中，设备管理单元110，还用于向服务器发送针对目标ecu140的诊断结果。
78.在一个示例，服务器还可以包括：显示屏，用于显示接收到的目标ecu140的诊断结果。
79.在一个示例，服务器还可以与终端设备连接，服务器用于向终端设备发送目标ecu140的诊断结果，使得终端设备显示该诊断结果。
80.基于此，可便于对诊断结果进行分析和处理。
81.在一种实施方式中，如图5所示，设备管理单元110、下载单元310以及文件传输单元320设置于信息域控制器510(information domain control module，idcm)中；
82.分发单元410、诊断解析单元120、诊断单元130设置于中央网关520(central gateway，cgw)中。
83.其中，信息域控制器510和中央网关520可以为两个独立的装置，信息域控制器510用于对诊断脚本的接收和验证等，中央网关520用于对诊断脚本进行解析以及执行诊断和收集诊断结果等。如此，可降低信息域控制器510和中央网关520之间的交互成本。
84.在一种实施方式中，如图6所示，设备管理单元110、下载单元310以及文件传输单元320、分发单元410、诊断解析单元120、诊断单元130设置于中央网关610中。
85.在本实施方式中，通过将车辆的各个单元集成在中央网关610中，可以提高设备管理单元110、下载单元310以及文件传输单元320、分发单元410、诊断解析单元120和诊断单元130的数据传输效率和数据传输稳定性，提高诊断效率和稳定性。
86.如图7所示，本申请实施例还提供一种诊断方法，应用于车辆，该诊断方法可以包括：
87.s701、车辆的设备管理单元接收诊断脚本；
88.s702、车辆的诊断解析单元对诊断脚本进行解析，得到诊断脚本所包含的至少一条诊断指令；
89.s703、车辆的诊断单元基于诊断脚本所包含的至少一条诊断指令对目标电子控制单元ecu执行诊断，并得到目标ecu对应的诊断结果。
90.在一个示例中，诊断脚本可以包含一条诊断指令，也可以包含多条诊断指令。
91.所述诊断脚本与目标ecu之间具备对应关系；其中，目标ecu可以是车辆的各个ecu中任意之一，各个ecu可以包括车身域控制器、网关、信息娱乐域控制器、电动助力转向控制系统、安全气囊控制器等，在此不做具体限制。也就是说，诊断脚本可以是以ecu为单位的，
不同的诊断脚本可以对应不同的ecu，当然，不同的诊断脚本也可以针对同一个ecu，根据实际情况来确定，这里不做穷举。
92.例如，诊断脚本a可以包含第一目标ecu的一条或多条诊断指令，诊断脚本b可以包含第二目标ecu的一条或多条诊断指令。
93.在一个示例中，当车辆的设备管理单元接收到诊断脚本a时，可以将该诊断脚本a传给所述诊断解析单元；所述诊断解析单元先对诊断脚本a进行解析，得到第一目标ecu对应的一条或多条诊断指令；诊断解析单元将针对所述第一目标ecu的一条或多条指令发送给诊断单元；进而诊断单元对第一目标ecu执行与该一条或多条诊断指令，最终得到第一目标ecu对应的诊断结果。这里，诊断单元执行一条或多条诊断指令的时候，可以依次接收到针对每一条诊断指令所对应的子诊断结果，诊断单元可以在接收到全部诊断指令所对应的子诊断结果之后，汇总得到总的诊断结果。如此，有利于对指定的目标ecu执行指定诊断，便于完成整个诊断任务流程。
94.需要指出的是，车辆的设备管理单元接收到的诊断脚本可以包括一个或多个；在接收到多个诊断脚本的情况下，设备管理单元可以依次将诊断脚本发送给诊断解析单元，相应的，诊断解析单元可依次对诊断脚本进行解析，诊断单元可依次对目标ecu执行诊断。
95.例如，当车辆的设备管理单元依次接收到诊断脚本a和诊断脚本b时，则诊断解析单元依次对诊断脚本a和诊断脚本b进行解析，以及诊断单元依次对第一目标ecu和第二目标ecu执行诊断；其中，第一目标ecu和第二目标ecu可以相同，可以不同。
96.根据本申请实施例的诊断方法，通过车辆的设备管理单元接收包含一条或多条诊断指令的诊断脚本，有利于提高诊断指令的接收效率，避免因网络中断而导致诊断指令的接收中断，可提高对诊断指令进行接收的稳定性；并且，由于诊断解析单元对诊断脚本的解析过程在车辆端进行，诊断单元可直接基于解析后的诊断指令对目标ecu执行诊断，因此，能够有效提高诊断执行的稳定性。
97.在一种实施方式中，如图8所示，接收诊断脚本时，该诊断方法还可以包括：
98.s801、车辆的设备管理单元通过与服务器之间的连接，从服务器获取诊断脚本和诊断脚本的配置文件，配置文件包含诊断脚本对应的诊断参数。
99.在一种实施方式中，如图9所示，方法还可以包括：
100.s901、车辆的下载单元从设备管理单元获取诊断脚本，对诊断脚本进行验证；
101.s902、车辆的下载单元在诊断脚本验证通过的情况下，将诊断脚本和诊断脚本的配置文件保存至车辆的文件传输单元。
102.在一种实施方式中，如图10，该诊断方法还可以包括：
103.s1001、车辆的分发单元获取诊断脚本的配置文件，对诊断脚本的配置文件进行解析得到诊断任务；
104.s1002、车辆的分发单元从文件传输单元获取诊断任务对应的诊断脚本。
105.在一种实施方式中，如图11所示，该诊断方法还可以包括：
106.s1101、车辆的诊断单元将目标ecu对应的诊断结果发送至文件传输单元；
107.s1104、车辆的下载单元从文件传输单元获取针对目标ecu对应的诊断结果。
108.在一种实施方式中，该诊断方法还可以包括：
109.车辆的设备管理单元向服务器发送针对目标ecu的诊断结果。
110.在一种实施方式中，设备管理单元、下载单元以及文件传输单元设置于信息域控制器idcm中；
111.分发单元、诊断解析单元、诊断单元设置于中央网关cgw中。
112.在一种实施方式中，设备管理单元、下载单元以及文件传输单元、分发单元、诊断解析单元、诊断单元设置于中央网关cgw中。
113.接下来，以车辆100中各个单元的一种交互流程为例对本申请实施例的车辆100进行说明。
114.如图5和图12所示，车辆100的各个单元进行诊断可以包括如下步骤：
115.s1201、服务器与车辆100的设备管理单元110建立连接，以与服务器进行通信；
116.s1202、设备管理单元110通过与服务器之间的通信连接，接收服务器发送的诊断脚本及其配置文件；其中，诊断脚本包含至少一条诊断指令；配置文件包含诊断脚本对应的诊断参数；
117.s1203、下载单元310从设备管理单元110获取诊断脚本及其配置文件；
118.s1204、下载单元310对诊断脚本进行验证；
119.s1205、下载单元310在验证通过的情况下，将诊断脚本及其配置文件(包含诊断参数)保存至文件传输单元320；
120.s1206、文件传输单元320对诊断脚本及其配置文件(包含诊断参数)进行保存；
121.s1207、下载单元310对诊断脚本的配置文件进行解析，得到与诊断脚本具有对应关系的诊断任务，并向分发单元410发送诊断任务；
122.s1208、分发单元410则根据诊断任务与诊断脚本之间的对应关系，从文件传输单元320中下载对应的诊断脚本；
123.s1209、分发单元410在检查车况是否正常；
124.s1210、分发单元410在检查车况正常的情况下，通知(或指示)诊断单元130发送开始诊断；
125.s1211、诊断单元130执行诊断并得到诊断结果。具体可以是，诊断解析单元120下载诊断脚本，将解析得到的诊断指令发送给诊断单元130；诊断单元130将诊断参数通过诊断指令写入到目标ecu140中执行诊断并得到诊断结果；
126.s1212、分发单元410从诊断单元130获取诊断结果；
127.s1213、分发单元410将获取到的诊断结果上传至文件传输单元320进行保存；
128.s1214、在完成保存的情况下，分发单元410还通过下载单元310下载诊断结果；
129.s1215、下载单元310则基于分发单元410的通知，下载对应的诊断结果；
130.s1216、在下载单元310完成下载后，将诊断结果传输至设备管理单元110；
131.s1217、设备管理单元110则将接收到的诊断结果上传到服务器进行显示、分析或处理。
132.需要说明的是，本交互流程中车辆100的各个单元的功能与上述实施方式中的功能基本相似，在此不再赘述。
133.图13a示出根据申请实施例的诊断系统的结构示意图。如图13a所示，该诊断系统包括：服务器1310和车辆100。
134.服务器1310，用于向车辆发送诊断脚本；
135.车辆110，用于接收诊断脚本；对所述诊断脚本进行解析，得到所述诊断脚本所包含的至少一条诊断指令；基于所述诊断脚本所包含的所述至少一条诊断指令，对目标电子控制单元ecu执行诊断，得到所述目标ecu对应的诊断结果。
136.所述服务器可以是远程诊断后台，或称为云端的远程诊断后台。
137.所述服务器1310，还用于获取诊断脚本；获取配置诊断脚本的配置文件；向车辆发送所述诊断脚本及其配置文件；以及接收所述车辆上传的所述诊断结果。
138.在一个示例中，服务器1310可用于：获取诊断脚本；获取配置诊断脚本的配置文件；向车辆100推送诊断脚本及其配置文件，以使车辆100执行诊断；接收车辆100上传的诊断结果。
139.另外，在诊断系统中还可以包括：远程诊断终端1320，用于展示所述服务器获取到的车辆的诊断结果。
140.还需要指出的是，所述诊断系统中还可以包括：诊断配置终端1330，用于生成诊断脚本，将所述诊断脚本上传至所述服务器1310。其中，生成诊断脚本的处理可以是基于运维人员的配置，比如可以配置至少一个诊断序列以生成诊断脚本，当然还可以存在其他的配置方式，这里不做穷举。
141.需要指出的是，诊断配置终端1330，还可以用于配置诊断策略，所述诊断策略用于指示诊断脚本的执行时间、诊断脚本对应的车辆、诊断脚本对应的ecu中至少之一。在一种场景中，诊断策略的配置为可选操作，比如需要对某一个诊断脚本配置其执行时间的时候，可以通过诊断配置终端进行其时间的配置，也就是说，在诊断脚本为定时执行的情况下，可以由运维人员在网络管理系统的诊断配置终端侧进行定时配置，进而生成该诊断脚本的诊断策略，将该诊断策略上传至服务器。进一步地，可以由服务器控制在诊断策略对应的执行时间到达的时候，将其对应的诊断脚本发送至车辆，进而由车辆基于诊断脚本执行诊断处理；又或者，服务器将诊断脚本及其对应的诊断策略均发送给车辆，车辆通过解析诊断策略可以确定诊断脚本的执行时间，在执行时间到达的时候，对诊断脚本进行解析等处理。这里，车辆执行的处理与前述实施例相同，因此不做赘述。
142.需要说明的是，上述诊断配置终端1330、远程诊断终端1320可以分别为两个设备，也可以是同一个设备，本实施例不对其进行限定。
143.最后需要指出的是，诊断系统中还可以包括管理设备1340，用于对运维人员的状态以及权限进行管理。比如，可以管理运维人员当前处于登录状态或非登录状态，或者，可以管理运维人员是否具备对某些功能的操作权限，或者管理运维人员是否具备对某些设备的操作权限等等。管理设备1340可以是管理人员使用的设备，可以通过该管理设备展示管理页面，以使得管理人员可以在管理页面上直观的查看并管理运维人员的状态。当然，管理设备1340可能还具备其他的功能，比如监督或查看或管理诊断系统中的网络侧的各个设备(比如前述诊断配置终端、远程诊断终端等)的状态等等，均可以在本实施例的保护范围内，这里不做穷举。
144.在一个示例中，如图13b所示，诊断系统中各个装置之间的交互流程可以包括：
145.s1301、诊断配置终端向服务器上传诊断脚本。
146.其中，诊断脚本可以基于诊断工程师对诊断序列配置工具的配置，自动生成；诊断序列配置工具可安装于服务器上，也可以安装在外部计算机上。
147.s1302(可选的)、诊断配置终端向服务器上传诊断脚本的诊断策略。
148.其中，关于诊断策略的内容以及相关处理在前述实施例已经说明，这里不做重复说明。
149.这里，在s1301以及s1302执行之前或执行过程中，还可以包括：管理设备对登录的终端设备进行身份认证与权限管理。其中，可通过服务器的管理页面的操作来对终端设备的权限进行管理，例如，对终端设备的权限或用户账号的权限进行增加和删除等操作管理。
150.s1303、服务器向车辆推送诊断脚本及其配置文件(含诊断参数)。
151.其中，诊断参数可从远程诊断终端中获取，也可以从其他外部设备中获取，诊断参数的获取方式可以根据实际的需要进行选择和调整，本申请实施对诊断参数的获取方式不作限制。
152.s1304、车辆执行诊断并得到诊断结果；
153.s1305、车辆向服务器上传诊断结果；
154.s1306、服务器向远程诊断终端发送诊断结果，在所述远程诊断终端上显示诊断结果。
155.需要说明的是，本申请实施例的诊断系统中各个装置的功能与上述实施方式相关联装置的功能基本相似，在此不再赘述。
156.本申请实施例各诊断方法中的车辆的各个单元之前的数据处理方法和数据交互方法可以参见上述装置中的对应描述，在此不再赘述。
157.图14示出根据本申请实施例的车辆的结构框图。如图14所示，该车辆包括：存储器1410和处理器1420，存储器1410内存储有可在处理器1420上运行的指令。处理器1420执行该指令时实现上述实施例中的诊断方法。存储器1410和处理器1420的数量可以为一个或多个。该车辆旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。车辆还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本申请的实现。
158.该车辆还可以包括通信接口1430，用于与外界设备进行通信，进行数据交互传输。各个设备利用不同的总线互相连接，并且可以被安装在公共主板上或者根据需要以其它方式安装。处理器1420可以对在车辆内执行的指令进行处理，包括存储在存储器中或者存储器上以在外部输入/输出装置(诸如，耦合至接口的显示设备)上显示gui的图形信息的指令。在其它实施方式中，若需要，可以将多个处理器和/或多条总线与多个存储器和多个存储器一起使用。同样，可以连接多个车辆，各个设备提供部分必要的操作(例如，作为服务器阵列、一组刀片式服务器、或者多处理器系统)。该总线可以分为地址总线、数据总线、控制总线等。为便于表示，图14中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
159.可选的，在具体实现上，如果存储器1410、处理器1420及通信接口1430集成在一块芯片上，则存储器1410、处理器1420及通信接口1430可以通过内部接口完成相互间的通信。
160.应理解的是，上述处理器可以是中央处理器(central processing unit，cpu)，还可以是其他通用处理器、数字信号处理器(digital signal processing，dsp)、专用集成电
路(application specific integrated circuit，asic)、现场可编程门阵列(field programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者是任何常规的处理器等。值得说明的是，处理器可以是支持进阶精简指令集机器(advanced risc machines，arm)架构的处理器。
161.本申请实施例提供了一种计算机可读存储介质(如上述的存储器1410)，其存储有计算机指令，该程序被处理器执行时实现本申请实施例中提供的方法。
162.可选的，存储器1410可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据诊断方法的车辆的使用所创建的数据等。此外，存储器1410可以包括高速随机存取存储器，还可以包括非瞬时存储器，例如至少一个磁盘存储器件、闪存器件、或其他非瞬时固态存储器件。在一些实施例中，存储器1410可选包括相对于处理器1420远程设置的存储器，这些远程存储器可以通过网络连接至诊断方法的车辆。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
163.在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包括于本申请的至少一个实施例或示例中。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
164.此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。
165.流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或多个(两个或两个以上)用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分。并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能。
166.在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。
167.应理解的是，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。上述实施例方法的全部或部分步骤是可以通过程序来指令相关的硬件完成，该程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。
168.此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以
是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。上述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读存储介质中。该存储介质可以是只读存储器，磁盘或光盘等。
169.以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到其各种变化或替换，这些都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。