CN115407742A - 用于诊断车辆的车载网络的方法 - Google Patents

Abstract

本发明涉及一种用于诊断车辆（100）的车载网络（101）的方法，所述车载网络包括彼此通信连接的多个计算单元（110、120、130），其中在所述多个计算单元中的一个计算单元（110）上执行诊断应用（114），其中所述诊断应用（114）从外部诊断单元（150）接收诊断请求，其中所述诊断请求由所述诊断应用（114）分析，以及其中所述诊断应用（114）基于所述诊断请求的内容向至少一个计算单元（120、130）发送数据和/或向所述外部诊断单元（150）发送诊断响应（240）。

Description

用于诊断车辆的车载网络的方法

技术领域

本发明涉及用于诊断车辆的车载网络的方法、用于执行该方法的计算单元和计算机程序以及这种车载网络。

背景技术

车辆的车辆网络（特别是数据车载网络）典型地包括多个不同的车辆控制设备，这些车辆控制设备直接或间接地相互通信连接。为此，使用通常不同的通信介质，例如总线（例如CAN总线或LIN总线或以太网）。为了诊断这样的车载网络——车辆诊断，可以使用外部诊断测试仪（通常也只简称为测试仪），它以通信（或数据传输）方式连接到车载网络。在此，诊断例如应理解为从车载电网或其控制设备请求各种信息或为车载电网或其控制设备预给定各种信息，必要时还具有控制设备的专用诊断运行模式。

发明内容

根据本发明提出了具有独立权利要求的特征的用于诊断的方法、用于执行该方法的计算单元和计算机程序以及车载网络。有利的设计是从属权利要求和以下描述的主题。

本发明涉及车辆的车载网络的诊断，该车载网络包括多个相互通信连接的计算单元（所谓的控制设备）。如所提到的，为了诊断这样的车载网络可以使用外部诊断测试仪或一般地外部诊断单元，所述外部诊断测试仪或外部诊断单元以通信（或数据传输）方式连接到车载网络。这例如可以在车间停留的范围内或在车辆开发期间进行。为此，通常为每个控制设备分配一个诊断地址。然后外部诊断单元可以通过该地址明确地对控制设备寻址。为此，诊断单元必须知道车辆中感兴趣控制设备的地址。

在现代车辆中，可以经由所谓的诊断网关访问控制设备。所述诊断网关基于诊断地址将来自诊断单元的诊断消息转发到被寻址的控制设备，并且将所述控制设备的响应对应地返回给所述诊断单元。在此，可以在诊断网关中进行地址转换，例如从逻辑地址转换为CAN标识符。但是，在使用诊断网关的情况下，诊断单元无法访问车辆内的信号，例如在网络上传输的实际值，因为所述信号不是由诊断网关转发的。

在本发明的范围内，现在提出了使用所谓的系统诊断软件。这是在车载网络的多个计算单元之一上执行的诊断应用（软件）。借助于这样的诊断应用——车辆中的软件组件，车辆中的多ECU系统（ECU在此代表“电子控制单元”，即控制设备）可以表示为与访问诊断单元相对的实体。为此，多ECU系统的诊断应用获得自己的地址，通过该地址可以对整个系统或车载网络进行寻址以用于诊断目的。这些诊断目的例如包括读取实际值和错误、控制执行器、启动例程和重新对系统编程。

在此，不仅控制设备或车辆控制设备可以用作计算单元，而且执行器和传感器也可以用作计算单元，只要它们具有对应的处理器等并且可以接收或发送数据或信号。同样，所谓的车辆中央计算机也在考虑之列；这些是性能强大的计算单元。原则上，车载网络中的任何计算单元都可以被认为是在其上执行诊断应用的计算单元，但是控制设备、特别是车辆中央计算机是适宜的。

然后在诊断期间，诊断应用从外部诊断单元（测试仪）接收诊断请求；然后由诊断应用分析该诊断请求，并且然后基于该诊断请求的内容，诊断应用将数据发送到（车载网络中）至少一个计算单元和/或将诊断响应发送到外部诊断单元。

为此，对诊断请求的分析特别是可以包括确定多个计算单元中在所述诊断请求中被寻址的至少一个计算单元，其中然后从诊断应用开始与至少一个被寻址的计算单元通信。

为了确定哪些计算单元被寻址，诊断应用优选地需要关于系统（或车载网络）的信息；这些信息在下文中也称为系统信息。这些信息例如包括将诊断信息分配给计算单元。因此，它特别是源信息，即关于必须将哪个消息转发到哪个（哪些）控制设备的信息。这些系统信息在此可以存储在诊断应用中（静态）或被学习（动态）。这可以例如最初或总是在控制设备上或控制设备中发生变化时（例如，在软件更新的情况下）进行。

在此，诊断请求可以包括不同类型的消息（诊断消息）。第一类型消息是服务消息。在这样的服务消息中，特别是对多个计算单元中的以下至少一个计算单元寻址，应当从所述至少一个计算单元读取诊断数据和/或将诊断数据传输到所述至少一个计算单元。这样的服务消息或必要时（包含在服务消息中）诊断数据由诊断应用转发到至少一个被寻址的计算单元。然后所涉及的计算单元将所述诊断数据返回给诊断应用，或者诊断应用接收所述诊断数据并且所述诊断数据作为诊断响应的一部分发送到外部诊断单元。

然而，涉及至少一个计算单元的诊断数据同样可以由诊断应用作为诊断响应的一部分发送到外部诊断单元，而无需事先将消息转发到计算单元。为此，诊断应用可以特别是分析在多个计算单元之间交换的数据和/或信号，并且基于此产生扩展的诊断信息，然后基于所述扩展的诊断信息确定所述诊断数据并作为诊断响应的一部分发送到外部诊断单元。

对所交换的数据或信号的这种分析以及基于此产生扩展的诊断信息可以优选地在时间上与诊断请求无关地进行，例如定期地、在出现事件时或总是在预定时间——例如在车载网络启动之后或启动时。然后所述扩展的诊断信息可以例如存储在存储器中，并在需要时使用。

所述扩展的诊断信息的来源特别是存储在系统信息中。

另一种类型的消息是控制消息，在所述控制消息中对多个计算单元中应当被置于预给定状态（例如专用诊断模式）的至少一个计算单元寻址，在所述预给定状态中输出不同于通常的数据和/或信号。为此，所述诊断应用特别是将所述控制消息转发给至少一个被寻址的计算单元和/或将至少一个被寻址的计算单元置于所述预给定状态。

另一种类型的消息是编程消息，在所述编程消息中恰好寻址多个计算单元中的一个计算单元，在所述一个计算单元中写入（例如用于控制单元软件的）程序数据和/或从所述一个计算单元读取程序数据。为此，特别是所述编程消息或待写入的程序数据由诊断应用转发给那一个被寻址的计算单元，和/或从那一个被寻址的计算单元接收程序数据，并且然后特别是作为诊断响应（或必要时作为诊断响应的一部分）发送到外部诊断单元。

因此，所述诊断应用收集并生成例如关于整个车载网络或系统的诊断信息。所述诊断应用根据请求（通过诊断请求）向诊断单元提供该信息（作为诊断响应）。只有所述诊断应用的地址用于与诊断单元的通信。为了收集信息可以使用各种方法的诊断应用。这包括例如诊断消息的转发；为此将获得的诊断消息基于其内容转发到一个或多个计算单元。从那里获得的信息然后由诊断应用作为车载网络或系统的信息传送到诊断单元。

所述诊断应用同样可以访问车载网络中的正常通信（包括数据或信号的交换）。为此，所述诊断应用从计算单元或控制设备彼此之间的通信中接收数据或信号（例如通过窃听网络），并从中生成扩展的诊断信息。为了产生整个系统的诊断信息，所述诊断应用可以组合来自两个可能性的信息。此外，所述诊断应用将例如诊断单元的特定诊断请求在需要时分发给一个或多个计算单元，例如在对系统重新编程时。可以想到，一方面诊断单元和诊断应用之间的通信以及另一方面诊断应用和被寻址的控制设备之间的通信使用不同的协议或通信协议。

在此，与诊断网关的区别特别是在于目标计算单元或目标控制设备的标识。所述标识基于诊断请求或诊断消息的内容，而不是基于控制设备的诊断地址。

总的来说，由此产生了各种优点。可以降低诊断单元的复杂性（需要更少的地址），并且可以将来自多个控制设备或计算单元的信息组合为诊断信息。迄今为止这一般在诊断单元中进行。

此外，可以进行扩展诊断。从而可以在诊断应用中从信号中产生扩展的诊断信息，例如用于系统的错误代码。在此，这些信号本身不必公开，而只需公开所述诊断信息。

扩展的诊断功能，例如用于系统预测诊断的算法，可以在诊断应用中实现并且不必公开，因为诊断应用只输出与诊断相关的信息，而不是信息的形成机制。

此外，减少了集成的耗费。在开发所述诊断时，只须将诊断应用作为诊断单元的实体已知。同样实现了简化的客户适配，因为例如不再需要在每个控制设备中实现新客户的诊断协议中的不同要求，而是可以由诊断应用来实现。

通过将来自不同控制设备的冗余信息组合成一个系统信息，可以开发基于系统的诊断。

根据本发明的计算单元（例如车辆的控制设备）被设置为，特别是以编程技术被设置为执行根据本发明的方法。

以具有用于执行所有方法步骤的程序代码的计算机程序或计算机程序产品的形式实现根据本发明的方法也是有利的，因为这导致特别低的成本，特别是在执行控制设备还用于其他任务并且因此无论如何都存在的情况下。适用于提供所述计算机程序的数据载体特别是磁的、光的和电的存储器，例如硬盘、闪存、EEPROM、DVD等。也可以经由计算机网络（互联网、内联网等）下载程序。

本发明的其他优点和设计由说明书和附图得出。

在附图中基于实施例示意性地示出本发明并且在下文中参照附图描述本发明。

附图说明

图1示意性地示出了车辆中处于优选设计的根据本发明的车载网络。

图2至图5示意性地示出了在优选实施方式中根据本发明的方法的流程。

具体实施方式

图1中示意性地示出了在车辆100中处于优选设计的根据本发明的车载网络101，其中可以执行在本发明范围内提出的诊断。车载网络101包括例如车辆中央计算机110、两个车辆控制设备120以及多个执行器和传感器130（在此不应区分执行器和传感器）。

这些是例如借助于一个或多个通信介质112彼此通信连接的计算单元。所述通信介质对所述计算单元之间的所有连接不一定必须相同，可以想到根据所述计算单元或待连接的计算单元的类型进行区分。从而例如更简单的传感器仅经由LIN连接，而更复杂的控制设备例如经由CAN或以太网连接。

在构造为车辆中央计算机的计算单元110上例如执行诊断应用114，也称为系统诊断软件。此外，在车辆100旁边示出了外部诊断单元150，即不属于车载网络或车辆的诊断单元，也称为诊断测试仪或测试仪。该外部诊断单元经由合适的通信连接连接到车载网络101，特别是连接到车辆中央计算机110。例如，可以为此使用所谓的OBD接口。在此，诊断单元150仅与车辆中央计算机上的诊断应用114通信，而不与其他计算单元通信。

图2中现在示出了在优选实施方式中的根据本发明的方法的流程的概览，即例如在图1中示出的车载网络或在图1特别是各个计算单元中的诊断流程。

首先，应当描述诊断应用的作用方式。当诊断应用与诊断单元或车载网络的计算单元或控制设备进行通信时，作为诊断协议例如使用在标准ISO14229-1：2020中定义的标准“Unified Diagnostic Services（统一诊断服务）”（UDS）。然而，诊断应用也可以使用替代协议来与计算单元进行通信。然后，诊断应用将来自测试仪的消息转换为其他协议或反过来。

作为协议变体，例如作为替代标准考虑在标准ASAM MCD-1中定义的“UniversalMeasurement and Calibration Protocol（通用测量和校准协议）”（XCP）以例如用于重新编程，所述协议通常在控制设备开发时使用。作为其他协议变体也可以使用对应定义和使用的专有协议。然后不必公开该专有协议（其仅用于诊断应用和车载网络中的计算单元之间的通信，而不用于诊断应用和测试仪之间的通信），由此更安全地保护计算单元或控制设备免受标准工具的攻击。

然后在诊断时，首先将测试仪与车载网络连接，从而可以与诊断应用进行通信。然后从测试仪向诊断应用发送诊断请求（请求）200，所述诊断应用接收该诊断请求。该诊断请求200可以包括不同类型的消息，即例如服务消息210、控制消息220或编程消息230。来自测试仪的这些消息然后可以例如转发到车载网络中的一个或多个计算单元。

这种转发可以使用不同的变体。一种变体是基于消息的；在此情况下诊断应用总是在将整个消息转发到计算单元之前才接收整个消息。另一个变体是基于帧的；在此情况下消息是分段传输的，例如在根据标准ISO 15765-2:2016-04的DoCAN（“Diagnosticcommunication over Controller Area Network，控制器局域网上的诊断通信”）中就是这种情况。消息也可以在每个接收到的帧之后同样逐帧转发。

下面应当更详细地讨论诊断的上级流程，在图2中示出该流程并且已简要解释过。在诊断应用中的程序流程开始时，在步骤250中使用系统信息211、221、231，更确切地说特别是根据消息的不同类型。这些系统消息可以包括（作为源）提供诊断信息（例如DTC、DID）的所有计算单元的数据。在此，作为计算单元或源可以考虑控制设备、执行器、传感器或诊断应用本身（也是在其上执行该诊断应用的计算单元）。

这些系统信息可以由不同的变体产生。一种可能性是静态产生。这些系统信息在此情况下静态存储在诊断应用中，并在控制设备中的软件改变时予以更新。

另一种可能性是学习式的产生。在此情况下，诊断应用通过从车载网络的计算单元或源读取来学习系统信息，例如在车载网络中的软件更新期间。这具有以下优点，即在控制设备的软件改变之后不必一定更新诊断应用。

在接下来的步骤212、222、232中访问系统信息，在这些步骤中处理消息210、220和230。如果诊断应用从测试仪接收到带有诊断请求200的消息，则首先例如基于服务标识（SID）在步骤202中键入该消息并根据类型转移到步骤212、222或232。

在此如前所述，这些消息分为例如以下类型：服务消息210是从车载网络或计算单元（以下为简单起见也称为系统）读取诊断信息或将诊断信息传输到车载网络或计算单元的消息。在UDS中是例如“ReadDataByIdentifier”、“InputOutputControlByIdentifier”或“ReadDTCInformation”。

控制消息220是应当将系统或特定计算单元置于特定状态的消息。在UDS中是例如“SessionControl”、“Authentication”或“ControlDTCSetting”。因此例如可以在计算单元中激活各种或不同的服务。

编程消息230是直接用于写入或读取控制设备软件（程序数据）的消息。在UDS中是例如“RequestDownload”、“TransferData”或“RequestTransferExit”。但是，也可以包括特殊的例程，例如用于删除或检查存储区的例程。

然后，根据消息的类型执行步骤或动作，其中必要时会获得响应（例如，如果消息被转发到计算单元，然后该计算单元返回响应），然后将该响应以诊断响应240的方式或作为诊断响应240的一部分发送回测试仪。由此完成了这条路径的遍历。新消息的到来重新启动该路径。

如果诊断应用例如经由正常通信从系统接收到内部数据的更新，则将更新的数据传递到块260。然后在该块260中生成扩展的诊断信息。可以在消息210到达时请求所述扩展的诊断信息。由此完成了这条路径。新更新的到来重新启动该路径。

图3中更详细地示出了服务消息210的处理。如果在步骤212的输入端处存在系统信息211和服务消息210，则执行后续活动。在步骤300中，基于服务消息的标识、可能的子功能以及一个或多个诊断信息，确定哪些源（计算单元）提供了它们（为此使用系统信息）。然后也从中产生源类型302以及因此得出必须如何将消息转发到控制设备或计算单元。

源类型可以是系统源310。每个控制设备和诊断应用都是所请求的（一个或多个）信息的源。在步骤312中，该消息在功能上被转发到所有控制设备。附加地，诊断应用在内部请求该信息。

源的类型可以是多源320（多个源）。多个（但不一定是全部）控制设备和/或诊断应用是所请求的（一个或多个）信息的源。在步骤322中，该消息被物理地转发到每个被标识（或寻址）为源的控制设备。在此，在转发之前，可以根据所请求的诊断信息对消息进行划分，从而只从每个源请求该源所提供的信息。如果诊断应用是源之一，则该诊断应用在内部请求对应的信息。

源的类型也可以是单个源330。控制设备或诊断应用是所请求的（一个或多个）信息的源。在步骤332中，消息被物理地转发到被标识为源的控制设备，或者诊断应用在内部请求所述（一个或多个）信息。

在步骤340中，收集源的响应并将这些响应组合为响应342。响应342经由输出端传输到上级流程，并且因此特别是作为诊断响应的一部分发送到诊断单元。

图4中更详细地示出了控制消息220的处理。如果在步骤222的输入端处存在系统信息211和控制消息220，则执行以下活动。在步骤400中，（仅）基于控制消息的标识，确定该控制消息是哪种转发类型402，即该控制消息是直接转发给所有控制设备还是存在特殊处理。

在没有设置直接转发的情况下，对控制消息存在特殊的处理或动作410。属于这些消息的有：“SecurityAccess”、“Authentication”和“TesterPresent”。可选地也可以转发最后一个消息。

例如，在前两个控制消息的情况下传输用于安全机制的信息，并在此基础上访问附加功能。这些机制可以在每个控制设备中以不同方式实现，因此在这里不能进行直接转发。在这种情况下，诊断应用应当知道每个控制设备中的机制并对应地与控制设备进行通信。然后，诊断应用从控制设备的响应中生成给外部测试仪的最终响应。

例如，“TesterPresent”是用于诊断应用的信息，即诊断应用应保持在先前检查的状态下。由于每个控制设备同样处于该状态，因此控制设备同样必须保持在该状态下。这既可以通过转发请求来进行，又可以通过独立于测试仪的请求而独立地周期性地将消息发送到控制设备来进行。

如果执行了特殊处理410，则响应430经由输出端传递给上级流程。

在系统源的情况下，消息在步骤420中功能性地转发给所有控制设备。在步骤425中，收集响应并组合为响应430。响应430经由输出端传递给上级流程。

图5中更详细地示出了对编程消息230的处理。如果在步骤232的输入端处存在系统信息231和编程消息230，则执行后续活动。在步骤500中，基于消息中的地址信息，确定将该消息转发到哪个控制设备。

在步骤510中，该消息被物理地转发到目标控制设备。在步骤520中，接收响应并经由输出端传递给上级流程。

总体而言，通过这种方式可以对具有大量计算单元或控制设备的车辆中的车载网络进行诊断，其中测试仪仅与诊断应用通信。与车载网络中的计算单元的通信通过诊断应用进行并且因此可以独立于测试仪进行，这例如涉及要使用的通信协议或还有随后实际转发的消息的选择。

Claims (16)

1.一种用于诊断车辆（100）的车载网络（101）的方法，所述车载网络包括彼此通信连接的多个计算单元（110、120、130），其中在所述多个计算单元中的一个计算单元（110）上执行诊断应用（114），

其中所述诊断应用（114）从外部诊断单元（150）接收诊断请求（200），

其中所述诊断请求（200）由所述诊断应用（114）分析，以及

其中所述诊断应用（114）基于所述诊断请求（200）的内容向至少一个计算单元（120、130）发送数据和/或向所述外部诊断单元（150）发送诊断响应（240）。

2.根据权利要求1所述的方法，其中，对所述诊断请求（200）的分析包括确定所述多个计算单元中在所述诊断请求（200）中被寻址的至少一个计算单元，以及其中从所述诊断应用（114）开始与至少一个被寻址的计算单元通信。

3.根据前述权利要求中任一项所述的方法，其中，如果所述诊断请求（200）包括服务消息（210），在所述服务消息中对所述多个计算单元中的至少一个计算单元寻址，应当从所述至少一个计算单元读取诊断数据和/或将所述诊断数据传输到所述至少一个计算单元，则由所述诊断应用（114）将所述服务消息（210）或所述诊断数据转发到至少一个被寻址的计算单元，和/或将涉及所述至少一个被寻址的计算单元的诊断数据作为所述诊断响应（240）的一部分发送到所述外部诊断单元（150）。

4.根据权利要求3所述的方法，其中，所述诊断应用（114）从所述至少一个被寻址的计算单元接收所述诊断数据并且作为所述诊断响应（240）的一部分发送到所述外部诊断单元（150）。

5.根据权利要求3或4所述的方法，其中，所述诊断应用（114）分析在所述多个计算单元（110、120、130）之间交换的数据和/或信号，并且基于此产生扩展的诊断信息（260），以及其中基于所述扩展的诊断信息确定所述诊断数据并作为所述诊断响应（240）的一部分发送到所述外部诊断单元（150）。

6.根据权利要求5所述的方法，其中，所述诊断应用（114）在时间上与诊断请求无关地对在所述多个计算单元之间交换的数据和/或信号进行分析以及基于此产生所述扩展的诊断信息（260）。

7.根据前述权利要求中任一项所述的方法，其中，如果所述诊断请求（200）包括控制消息（220），根据所述控制消息（220）对所述多个计算单元中应当被置于预给定状态的至少一个计算单元寻址，则由所述诊断应用（114）将所述控制消息（220）转发给至少一个被寻址的计算单元和/或将至少一个被寻址的计算单元置于所述预给定状态。

8.根据前述权利要求中任一项所述的方法，其中，如果所述诊断请求（200）包括编程消息（230），在所述编程消息中恰好寻址多个计算单元中的一个计算单元，在所述一个计算单元上写入程序数据和/或从所述一个计算单元读取程序数据，则由诊断应用（114）将所述编程消息（230）或待写入的程序数据转发给被寻址的计算单元，和/或从被寻址的计算单元接收程序数据，并且特别是作为所述诊断响应（240）的一部分发送到所述外部诊断单元（150）。

9.根据前述权利要求中任一项所述的方法，其中，基于系统信息（211、221、231）确定对哪个计算单元寻址，并且其中所述系统信息特别是最初和/或重复地存储在所述诊断应用（114）中。

10.根据权利要求9所述的方法，其中，所述系统信息（211、221、231）是通过读取所述多个计算单元来动态确定或生成的。

11.根据前述权利要求中任一项所述的方法，其中，所述诊断应用（114）借助于第一协议接收所述诊断请求（200），并且借助于不同于所述第一协议的第二协议将数据发送到所述至少一个计算单元（120、130）。

12.根据前述权利要求中任一项所述的方法，其中，所述多个计算单元（110、120、130）选自：车辆中央计算机、车辆控制设备、执行器和传感器。

13.一种计算单元（110），其被设置为执行根据前述权利要求中任一项所述的方法的所有方法步骤。

14.一种车辆（100）的车载网络（101），所述车载网络具有多个计算单元（110、120、130），所述多个计算单元彼此通信连接并且其中一个计算单元被构造为根据权利要求13所述的计算单元（110）。

15.一种计算机程序，当其在计算单元（110）上执行时促使所述计算单元（110）执行根据权利要求1至12中任一项所述的方法的所有方法步骤。

16.一种机器可读存储介质，具有存储在其上的根据权利要求15所述的计算机程序。

Images