CN114341758A - 用于面向服务的车辆诊断的电气架构 - Google Patents

用于面向服务的车辆诊断的电气架构 Download PDF

Info

Publication number
CN114341758A
CN114341758A CN202080061635.6A CN202080061635A CN114341758A CN 114341758 A CN114341758 A CN 114341758A CN 202080061635 A CN202080061635 A CN 202080061635A CN 114341758 A CN114341758 A CN 114341758A
Authority
CN
China
Prior art keywords
diagnostic
service
vehicle
module
electrical architecture
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202080061635.6A
Other languages
English (en)
Inventor
迪比延都·帕莱
萨钦·欣德
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Jaguar Land Rover Ltd
Original Assignee
Jaguar Land Rover Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Jaguar Land Rover Ltd filed Critical Jaguar Land Rover Ltd
Publication of CN114341758A publication Critical patent/CN114341758A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0808—Diagnosing performance data
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • B60R16/0231—Circuits relating to the driving or the functioning of the vehicle
    • B60R16/0232—Circuits relating to the driving or the functioning of the vehicle for measuring vehicle parameters and indicating critical, abnormal or dangerous conditions
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/02—Ensuring safety in case of control system failures, e.g. by diagnosing, circumventing or fixing failures
    • B60W50/0205—Diagnosing or detecting failures; Failure detection models
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00—Testing or monitoring of control systems or parts thereof
    • G05B23/02—Electric testing or monitoring
    • G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0218—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults
    • G05B23/0243—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults model based detection method, e.g. first-principles knowledge model
    • G05B23/0245—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults model based detection method, e.g. first-principles knowledge model based on a qualitative model, e.g. rule based; if-then decisions
    • G05B23/0251—Abstraction hierarchy, e.g. "complex systems", i.e. system is divided in subsystems, subsystems are monitored and results are combined to decide on status of whole system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/42—Bus transfer protocol, e.g. handshake; Synchronisation
    • G06F13/4282—Bus transfer protocol, e.g. handshake; Synchronisation on a serial bus, e.g. I2C bus, SPI bus
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2213/00—Indexing scheme relating to interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F2213/0002—Serial port, e.g. RS232C

Abstract

一种在车辆的诊断电气架构中提供诊断通信的方法，车辆包括用于托管诊断电气架构的多个车载计算设备。诊断电气架构包括：一个或更多个电子控制单元，每个电子控制单元包括诊断服务器模块；服务接口模块，服务接口模块被布置成允许一个或更多个电子控制单元与车辆的网络服务总线之间的诊断通信；以及诊断服务注册模块。该方法包括：由诊断服务器模块执行诊断任务以生成诊断对象数据；将所生成的诊断对象数据接收到服务接口模块中；从诊断服务注册模块检索诊断服务数据，诊断服务数据包括所生成的诊断对象数据的诊断能力描述；以及通过网络服务总线传送诊断服务通知，该诊断服务通知是基于所生成的诊断对象数据和诊断服务数据。

Description

用于面向服务的车辆诊断的电气架构
技术领域
本公开内容涉及用于车辆的诊断电气架构，并且具体地，涉及托管在多个车辆车载计算设备上的诊断电气架构。本发明的各方面涉及车辆诊断电气架构、方法、计算机可读介质和车辆。
背景技术
现代车辆——例如道路车辆如汽车——包括用于控制和执行车辆的多个功能的多个嵌入式电子控制单元、组件或模块(ECU)。这样的ECU的示例可以包括防抱死制动系统(ABS)、动力总成控制模块(PCM)、变速箱控制模块(TCM)、仪表面板组(IPC)、ADAS域控制器(ADC)、引擎管理系统(EMS)、空气调节模块(ACM)等。通常，每个车辆ECU连接至车辆的多个传感器，并且接收来自传感器的传感器数据连同来自车辆的其他部件的信号作为输入。
ECU的电子部件或软件、或者连接至ECU的传感器可能失效或产生故障。许多ECU将包括具有自诊断能力的本地诊断服务器，自诊断能力包括能够识别和报告故障，并且可能执行对故障的自修复。
目前，车辆的诊断测试涉及诊断测试器——可以是车载或非车载的——在诊断测试器与车辆的任何ECU的本地诊断服务器之间建立点对点(p2p)诊断通信。特别地，这样的诊断通信经由单个中央网关进行，该单个中央网关用作诊断消息到特定本地诊断服务器的路由器，特别是用于在不同传输协议之间路由诊断消息。
存在与上述现有车辆诊断架构相关联的许多潜在的缺点或弊端。这些缺点或弊端包括但不限于：静态诊断配置、缺乏诊断冗余、限制于基于组件的诊断、一次限于对一个测试器的诊断访问、以及在外部测试器与车辆模块之间没有逻辑分隔和物理分隔而导致安全风险。本发明的目的是解决与现有技术相关联的缺点中的一个或更多个缺点。
发明内容
根据本发明的一方面，提供了一种用于车辆的诊断电气架构，车辆例如是汽车或其他道路行驶车辆。车辆包括用于托管诊断电气架构的多个车载计算设备。诊断电气架构包括一个或更多个电子控制单元，每个电子控制单元包括诊断服务器模块，诊断服务器模块被布置成执行诊断任务以生成诊断对象数据。该架构包括服务接口模块，服务接口模块被布置成允许所述一个或更多个电子控制单元与车辆的网络服务总线之间的诊断通信，服务接口模块被布置成接收所生成的诊断对象数据。该架构包括诊断服务注册模块，诊断服务注册模块被布置成存储指示由服务接口模块提供的诊断服务的诊断服务数据，诊断服务数据包括所生成的诊断对象数据的诊断能力描述。服务接口模块被布置成通过网络服务总线传送诊断服务通知，其中，诊断服务通知是基于所生成的诊断对象数据和从诊断服务注册表检索的诊断服务数据。
诊断服务通知可以是响应于由服务接口模块提供的诊断能力的变化而生成的。
诊断能力的变化可以是由所述一个或更多个控制单元执行的诊断任务的添加或移除引起的。
诊断能力的变化可以是由与服务接口模块相关联的电子控制单元的添加或移除引起的。
诊断服务通知可以是响应于由服务接口模块接收到的对诊断能力的请求而生成的。
对诊断能力的请求可以是从非车载诊断测试器接收的。
所生成的服务通知可以在车辆外传送。
所生成的诊断能力通知可以用于更新诊断注册模块。
服务接口模块可以部署在车载计算设备中的一个或更多个上的通信中间设备上。
通信中间设备可以是以下之一：SOME/IP(基于IP的可扩展的面向服务的中间设备)；REST(表征状态转移)；以及DDS(数据分发服务)。
车辆服务总线可以包括以太网骨干网络。
服务接口模块可以直接连接至以太网骨干网络。
所存储的诊断服务数据可以包括用于解释诊断对象数据的开放诊断交换(ODX)文件。
诊断服务注册模块可以被布置成允许车载模块和非车载模块订阅诊断服务注册模块，使得车辆上模块和车辆外模块动态地学习由服务接口模块提供的诊断服务。
诊断电气架构可以被布置成提供统一诊断服务(UDS)协议通信与面向服务的诊断通信之间的转换。
诊断电气架构可以是具有组件诊断层和至少一个监督诊断层的层次化架构，组件诊断层包括所述一个或更多个电子单元。
所述至少一个监督诊断层可以包括服务接口模块。
所述至少一个监督诊断层可以包括诊断服务注册模块。
所述至少一个监督诊断层可以包括系统诊断层和车辆诊断层，车辆诊断层相比于系统诊断层处于架构的更高层级。车辆诊断层可以包括服务接口模块，并且系统诊断层可以包括应用服务模块，应用服务模块包括本地诊断代理，本地诊断代理被布置成汇总从电子控制单元接收的所生成的诊断服务通知以生成监督级诊断服务通知。
监督级诊断服务通知可以用于更新诊断服务注册模块。
服务接口模块可以托管在车辆的区域输入/输出计算设备或车辆的中央计算平台上。
根据本发明的另一方面，提供了一种车辆，例如汽车或其他道路行驶车辆，该车辆包括具有多个计算设备并托管上述诊断电气架构的网络架构。
根据本发明的另一方面，提供了一种在车辆的诊断电气架构中提供诊断通信的方法，所述车辆例如是汽车或其他道路行驶车辆。车辆包括用于托管诊断电气架构的多个车载计算设备。诊断电气架构包括：一个或更多个电子控制单元，每个电子控制单元包括诊断服务器模块；服务接口模块，服务接口模块被布置成允许所述一个或更多个电子控制单元与车辆的网络服务总线之间的诊断通信；以及诊断服务注册模块。该方法包括由诊断服务器模块执行诊断任务以生成诊断对象数据，以及将所生成的诊断对象数据接收到服务接口模块中。该方法包括从诊断服务注册模块检索诊断服务数据，诊断服务数据包括所生成的诊断对象数据的诊断能力描述。该方法包括通过网络服务总线传送诊断服务通知，诊断服务通知是基于所生成的诊断对象数据和诊断服务数据。
根据本发明的另一方面，提供了一种非暂态计算机可读存储介质，其上存储有指令，所述指令在由一个或更多个处理器执行时使所述一个或更多个处理器执行上述方法。
在本申请的范围内，明确地旨在，在前面的段落中、权利要求中和/或下面的描述和附图中阐述的各个方面、实施方式、示例和替选方案以及特别是其各个特征可以被独立地采用或者以任意组合采用。也就是说，所有实施方式和/或任何实施方式的特征可以以任何方式和/或组合进行组合，除非这些特征不兼容。申请人保留改变任何原始提交的权利要求或相应地提交任何新的权利要求的权利，包括修改任何原始提交的权利要求以从属于任何其他权利要求和/或并入任何其他权利要求的任何特征的权利，尽管最初没有以该方式要求保护。
附图说明
现在将参照附图仅以示例的方式来描述本发明的一个或更多个实施方式，在附图中：
图1示出了具有平坦(flat)、非层次化结构的车辆诊断电气架构，该平坦、非层次化结构利用了面向信号的诊断通信；
图2示出了根据本发明另一示例的车辆诊断电气架构，该车辆诊断电气架构具有利用了面向服务的诊断通信的层次化结构；
图3示出了图2的诊断电气架构的应用服务模块；
图4示出了车辆网络架构，该车辆网络架构包括多个计算设备，该车辆网络架构指示图2的诊断电气架构的各层被托管的位置；
图5示出了用于车辆方向指示器特征的图2的车辆诊断电气架构；
图6示出了使用图2的车辆诊断电气架构执行车辆诊断通信的方法的步骤；
图7示出了根据本发明的一方面的示例的车辆，该车辆包括托管图2的诊断电气架构的图4的网络架构；以及
图8示出了车载计算设备的简化示例。
具体实施方式
图1示出了车辆的点对点(p2p)诊断电气架构10。车辆诊断架构10具有多个电子控制单元、组件或模块(ECU)101，这些ECU 101在逻辑上被布置在平坦的非层次化结构10或组件级诊断架构10中。ECU 101各自分别执行单独的功能，并且可以包括防抱死制动系统模块(ABS)、动力总成控制模块(PCM)、变速器控制模块(TCM)、仪表面板组(IPC)、ADAS域控制器(ADC)、引擎管理系统(EMS)和/或空调模块(ACM)。应当理解，车辆诊断架构10可以包括任何数量的合适的ECU。通常，车辆可以包括40至60个ECU。
诊断架构10中的每个ECU 101可以与车载或非车载诊断测试器11通信。实际上，诊断测试器11能够直接建立与任何车载ECU 101的诊断通信路径。因此，诊断测试器11能够启动诊断通信并执行各种诊断任务例如启动ECU 101中的任一ECU 101的按需自测试(ODST)，使得与ECU相关联的故障被报告回测试器11。特别地，使用网关模块(GWM)12实现各ECU 101与诊断测试器11之间的诊断通信。诊断测试器11可以是任何合适的车辆诊断测试器，例如工程、制造或服务测试器，经连接的诊断测试器或者车载诊断或空中软件(SOTA)测试器。实际上，车辆通常具有多个不同的与车载ECU通信的诊断测试器。
诊断电气架构10中的每个ECU 101具有本地诊断服务器或模块102。每个诊断服务器102被布置成执行与其相应ECU 101相关联的自诊断操作，包括识别、报告和/或修复ECU101的部件或软件或与ECU 101相关联的传感器的故障或失效。然后，诊断服务器102将任何识别到的故障或错误报告回诊断测试器11，并且向诊断测试器11通知已经执行的任何自修复操作。
诊断架构10中的ECU 101是存在于车辆中的不同网络的一部分，所述网络例如CAN(控制器局域网)、LIN(本地互连网络)、FlexRay和以太网。这些网络中的每种网络均具有不同的协议和数据传输速率。例如，LIN用于低速网络如传感器和致动器，数据速率为约20kbps，CAN可以用于不同ECU之间的通信，数据速率为约1Mbps至5Mbps，FlexRay可以用于安全关键应用，数据速率为约10Mbps，并且以太网可以用于信息娱乐系统、高级驾驶员辅助系统(ADAS)以及无线接口例如4G、Wi-Fi等，数据速率范围为每秒兆比特至每秒千兆比特。
从逻辑观点来看，GWM 12为诊断测试器11与具有ECU 101的组件级诊断架构10之间的通信提供单个进入点。GWM 12充当从一个网络到另一个网络(例如从以太网帧到CAN总线帧，并且反之亦然，例如从CAN总线帧到以太网帧)的诊断消息的路由器。特别地，GWM 12桥接在诊断测试器11的外部或非车载网络与车辆ECU 101的内部或车载网络之间。
在诊断测试器11与ECU 101之间使用的诊断协议是在ISO标准14229-1中定义的统一诊断服务(UDS)协议。特别地，针对各种不同底层网络技术的诊断通信的UDS协议已经在各种ISO标准中得到解决和规定：ISO 14229-3规定了CAN上的UDS；ISO 14229-4规定了FlexRay上的UDS；并且ISO 14229-5规定了互联网协议上的UDS。UDS协议继续用于诊断通信的目的，而与车辆电气架构中使用的底层网络技术无关。这可能限制可以交付的诊断能力，同时还限制整个诊断电气架构的可扩展性和/或灵活性。
标准化诊断传输协议DoIP(基于互联网协议的诊断通信)与UDS协议结合使用，以将诊断消息封装在以太网帧中用于诊断测试器11与车辆ECU 101的通信。因此，GWM 12将DoIP以太网帧从诊断测试器11路由至针对要向其发送诊断消息的特定ECU 101的相关传输协议，例如CAN、LIN、FlexRay帧等。也就是说，诊断测试器11经由DoIP网关模块12与车辆架构(即组件级诊断架构)10中的各个ECU 101建立p2p诊断通信，并且UDS被用作整个诊断电气架构10中的诊断通信的协议。
车辆中的单次故障或失效可能导致多个ECU 101故障。这些ECU 101中的每个ECU101将检测并报告与该特定ECU 101相关或相关联的故障，并且将这些故障报告回诊断测试器11。这意味着诊断测试器11可以从多个不同的ECU 101接收多个故障代码，故障代码也被称为诊断故障代码(DTC)。然后，诊断测试器11或工程师或服务技术人员必须分析并解译所接收的DTC，以确定多个DTC的根本原因，并且因此确定需要执行的正确诊断修复。
尽管许多不同的诊断测试器可以访问ECU 101，但是在任一时刻仅单个诊断测试器可以与组件级诊断架构10建立诊断通信。因此，可以在GWM 12中设置不同诊断测试器之间的相对优先级。例如，第三方非车载测试器例如OBD扫描工具或保险软件狗可以被分配最高优先级，制造商非车载测试器可以被分配次高优先级，而车载SOTA可以被分配最低优先级。
本发明提供如下车辆诊断电气架构：在所述车辆诊断电气架构中，将车辆特别是车辆的ECU的诊断能力作为诊断服务通过车辆的网络服务总线提供给例如非车载诊断测试器和/或其他车载模块。这与图1中的诊断电气架构10的面向信号的p2p诊断通信形成对比。例如，尽管图1的电气架构中的各个ECU可以用具有与所执行的诊断测试相关的原始诊断对象数据的信号来响应诊断测试器(其中，原始数据于是必须在车辆外被解译)，但是在本发明中，ECU可以用与所执行的诊断测试相关的经解译或评估的数据或值来响应诊断测试器。这将在下面详细描述。
图2示出了车辆的另一诊断电气架构20。与图1不同，在图2中，架构20是车辆的层次化诊断架构20。这也可以被称为分层式诊断架构20。与图1的非层次化架构10不同，层次化架构20包括多个诊断层21、22、23。与图1的非层次化架构10类似，层次化架构20具有组件诊断层21，组件诊断层21包括各自分别用于在车辆上执行不同功能的多个ECU 211。
层次化诊断架构20中的每个ECU 211具有本地诊断服务器或模块212。每个诊断服务器212提供如下能力：读取与相关联的ECU 211相关联的故障记录数据并启动ECU自测试，以确定针对ECU的所有输入和输出是否如设计的那样连接、配置和运作，以及ECU的部件或软件及连接至ECU的传感器是否在正确运作。除了用于从ECU 211检索故障数据的这些“拉”机制之外，ECU 211还能够例如在检测到故障时或在发生预定义事件或触发时将故障数据“推”或传送至层次化诊断架构20的较高级别或较高层22、23。
与图1的非层次化架构10不同，层次化架构20还包括在组件诊断层21之上或在组件诊断层21与车载或非车载诊断测试器24之间的两个监督诊断层22、23，诊断测试器24被布置成与层次化诊断架构20进行诊断通信。提供这样的监督层22、23使得能够在比由组件诊断层21中的ECU 211提供的组件级诊断高的级别处进行诊断监测和报告。尽管在组件诊断层21中执行的诊断被限制为独立于其他ECU确定和报告与特定ECU相关联的故障，但是监督层具有较低层21中的多个不同ECU 211的概况，并且因此在监督层中执行的诊断可以汇总来自多个不同ECU 211的故障数据——或者更一般地，来自较低层的故障数据——以提供车辆系统的更清楚的诊断概况。
在所描述的示例中，层次化诊断架构20包括在组件诊断层21上的系统诊断层22以及在系统诊断层22上并且被布置成与诊断测试器24进行诊断通信的车辆诊断层23。在系统诊断层22中，针对多个应用服务中的每个应用服务对来自多个ECU 211的故障数据进行分析和解译。每个应用服务需要由某些单独的组件或ECU 211提供的某些功能。作为示例，可以供应或提供车辆速度作为车辆的应用服务。为了确定车辆速度，需要车辆的四个车轮速度传感器中的每一个提供车轮速度传感器信号。
然后可以针对基于来自相关ECU的故障数据而提供的不同应用服务中的每个应用服务在“服务级”执行诊断。特别地，系统诊断层22包括各自分别连接至组件诊断层21中的多个ECU 211的多个应用服务接口模块221。注意，给定ECU 211可以经由层次化结构向多个不同的应用服务模块221提供故障数据。然后可以将诊断通知从应用服务模块221发送至架构20的较高层，在这种情况下所述较高层为车辆诊断层23。系统诊断层22还包括可以用于存储来自组件诊断层21中的ECU 211的故障数据或其他通知的本地数据库或寄存器222。
在车辆诊断层23中，针对多个面向客户的车辆特征中的每个特征对来自多个应用服务模块221的故障数据进行分析和解译。这些用户特征可以被认为是可用于辅助用户驾驶车辆的车辆特征，或者是向车辆用户提供娱乐、舒适度等的其他车辆特征。这样的车辆特征可以包括例如方向指示器特征或车道改变辅助特征。
然后可以针对基于来自相关应用服务模块221的故障数据而提供的不同车辆用户特征中的每个车辆用户特征在“车辆级”或“车辆特征级”执行诊断。特别地，车辆诊断层23包括连接至系统诊断层22中的应用服务模块221的平台诊断服务模块231。然后，可以将诊断通知从平台诊断服务模块231发送至车载或非车载的诊断测试器24。车辆诊断层23还包括可以用于存储来自系统诊断层22中的应用服务模块221的故障数据或其他通知的中央数据库或寄存器232。中央数据库232还包括由车辆提供的当前应用服务列表，可以随时间推移添加或修改该列表。
图3更详细地示出了图2中的应用服务模块221之一。特别地，每个应用服务模块221包括本地诊断代理2211，本地诊断代理2211在某些方面与ECU的诊断服务器212类似。特别地，本地诊断代理2211与相关联的应用服务模块221集成在一起，并且直接访问到模块221的所有输入和来自模块221的所有输出，以及直接访问应用服务模块221的内部状态。也就是说，本地诊断代理2211连接至模块221的输入2212、输出2213和内部状态2214的相应接口。在图2的示例中，本地诊断代理2211则可以基于所访问的数据(其可以包括例如从多个ECU 211接收的故障数据)在层次化网络架构20的“服务级”执行诊断。
图4示出了包括设置在车辆中的多个已连接计算设备的车辆网络架构40。网络架构40包括中央计算平台(CCP)41。CCP 41经由以太网数据主干42连接至呈域控制器或分区计算平台(CP)或者远程输入/输出(RIO)模块43形式的多个其他计算平台。这些CP和RIO 43各自分别还经由常规网络44(例如CAN、FlexRay或LIN)连接至多个ECU 211。
可以通过使用常规处理器或客户处理器以及存储器在任何合适的计算基板上运行合适的软件来提供计算设备。计算设备中的一些计算设备可以使用公共计算基板(例如，它们可以在同一服务器上运行)或单独的基板，或者计算设备中的一个或一些计算设备本身可以分布在多个计算设备之间。
在说明性描述的示例中，CCP 41沿着以太网主干网络连接至四个CP和RIO 43，特别地，连接至三个RIO模块431、432、434和ADC(ADAS域控制器)433。在架构20的情况下，第一RIO 431沿着常规网络44连接至三个ECU 211，特别地，连接至ABS模块2111、PCM 2112和TCM2113。ABS模块2111还连接至用于车辆的四个车轮中的相应车轮的四个车轮速度传感器45。第二RIO 432沿着常规网络44连接至IPC 2114和多个其他外围模块或ECU 2115。第n RIO434还沿着常规网络44连接至多个外围模块2116、2117、2118。
图2的层次化诊断架构20中的不同诊断层21、22、23被托管在车辆网络架构40的不同计算机设备或模块上。特别地，如图4中所指示的，车辆诊断层23被托管在CCP 41上，系统诊断层22被托管在CP/RIO 43和/或CCP 41上，并且组件诊断层21被托管在ECU 211和/或CP/RIO 43上。
与图1的架构10的“面向信号的”诊断不同，图2的架构20的“面向服务的”诊断不使用UDS作为整个诊断架构20中的诊断通信的协议。与车辆建立诊断通信的诊断测试器24直接支持面向服务的诊断接口，或者平台诊断服务模块231执行从UDS(在测试器24与平台诊断服务模块231之间)到面向服务的诊断通信(在平台诊断服务模块231与车辆架构20的其余部分之间)的转换，并且反之亦然，执行从面向服务的诊断通信到UDS的转换。
通过以太网数据主干42连接的各个RIO 43经由应用服务模块221提供应用服务。这些应用服务可由测试器24或车辆的其他组件/模块通过网络服务总线42订阅、取消订阅。注意，没有直接连接至以太网主干网络42的模块不能提供诊断服务。在图2的示例中，应用服务模块221是服务层22的一部分，服务层22被托管在CCP 41和/或RIO 42上。如图4可见，由于CCP 41和/或RIO 42直接连接至以太网主干42，因此在这种情况下，应用服务模块221总是直接连接至以太网主干42。在(外围)模块/ECU没有直接连接至以太网主干并且因而不能提供诊断服务的情况下，则它们可以通过常规子网(例如CAN、LIN、FlexRay)之一来发布用于诊断服务的等效网络信号接口。然后，托管在RIO 43上的诊断信号管理器模块对来自ECU的诊断信号与提供给例如测试器的诊断服务之间的映射进行管理。也就是说，诊断信号管理器充当以太网数据主干与CAN/LIN/FlexRay网络的各个子网之间的本地网关。
参照图4，描述了用于突出具有本地诊断代理的面向服务的诊断架构的益处的示例。特别地，在该示例中，提供车辆速度作为服务，其中车轮速度信号来自四个车轮速度传感器中的每一个车轮速度传感器即用于车辆的每个车轮的一个车轮速度传感器。
ABS模块2111从经由常规网络44连接至ABS 2111的四个车轮速度传感器45接收车轮速度。直接连接至以太网主干42的RIO#1模块431根据通过常规网络44从ABS模块2111接收到的车轮速度信号计算车辆速度。然后，RIO#1模块431将车辆速度作为服务提供给参与面向服务架构的模块，其中服务的质量被添加至服务接口。然后，RIO#1模块431通过连接至RIO#1模块431的常规网络44将计算的车辆速度信号路由回。
然后，直接连接至以太网主干网络42的其他模块可以订阅RIO#1模块431中提供的车辆速度服务。例如，RIO#2模块432订阅车辆速度服务并且将其用作模块432上托管的应用/服务的输入。另外，RIO#2模块432提供从面向服务的通信至面向信号的通信的反向转换，并且通过连接至RIO#2模块432的常规网络44传输获得的车辆速度信号。此外，ADC模块433从以太网服务总线42订阅车辆速度服务并且将该车辆速度服务用于其自身的应用/服务。
PCM 2112和TCM 2113通过常规网络44连接至RIO#1模块431，并且因此这些模块2112、2113接收由RIO#1模块431传输的车辆速度信号以传递其自身的功能。类似地，IPC模块2114通过常规网络44连接至RIO#2模块432，并且因此IPC模块2114接收由RIO#2模块432传输的车辆速度信号以传递其自身的功能。
在诊断方面，与车轮速度传感器或信号相关的故障或失效可以在服务级别上报告，这有利地可以提供失效的解释视图而不是原始的诊断故障代码(DTC)，这然后需要在车辆外对其进行分析以找到失效的根本原因。
例如，如果车轮速度传感器45中的第一个出现故障，则这将由ABS模块2111中的诊断服务器检测到，该ABS模块2111将生成DTC，例如针对车轮速度传感器45存在短路或开路。参照图4，车轮速度传感器45的失效也将由RIO模块#1 431检测到，该RIO模块#1 431也将生成DTC，例如已经接收到来自车轮速度传感器45的无效串行数据。在面向信号的诊断架构中，可能会报告这些单独的DTC中的两个，并且然后需要对潜在故障或根本故障进行分析。相比之下，在面向服务的诊断架构中，DTC的分类可以在系统诊断层22中执行——特别是在应用服务模块的本地诊断代理2211中执行——以确定引起多个DTC的根本故障。在这种情况下，分类确定车轮速度传感器45有故障，并且因此仅报告由ABS模块2111生成的DTC代码。
作为另一示例，并且继续参照图4，考虑其中车轮传感器45中的三个出现故障的情况。在这种情况下，ABS模块2111将生成三个DTC，即三个车轮速度传感器45中的每一个都存在短路或开路。RIO模块#1 431还将生成三个DTC，即已经接收到来自三个故障车轮速度传感器45中的每一个的无效串行数据。然而，与前面的示例不同，如果三个车轮速度传感器故障，则无法进行车辆速度的计算，使得由RIO模块#1 431无法提供车辆速度作为服务。如以上概述的，存在车辆的许多模块利用计算的车辆速度信号。当车辆速度服务没有作为沿以太网网络42的服务被接收时，RIO模块#2 432生成DTC，例如无效的车辆速度信号，并且IPC模块2114也生成DTC，例如信号真实性失效，因为转向柱无法解锁，或者由于不正确的车辆速度因此无法启动发动机。此外，ADC模块433也利用车辆速度服务，例如作为巡航控制功能的一部分，并且因此当车辆速度没有作为沿以太网网络42的服务被接收时，ADC模块433生成DTC，例如无效的车辆速度信号。另外，PCM 2112和TCM 2113可以使用由RIO模块#1431沿常规网络44传输的车辆速度信号，并且因此这些模块在没有接收到车辆速度信号时将会生成DTC。在面向信号的诊断结构中，可能会报告这九个单独的DTC(针对TCM 2113的两个)中的每一个，并且然后将需要对潜在故障或根本故障进行分析。相比之下，在面向服务的诊断架构中，可以在系统诊断层22(在这种情况下由域控制器431、432、433托管)和车辆诊断层23(在这种情况下在CCP 41中托管)中执行DTC的服务级别分析，以确定引起多个DTC的根本故障。在这种情况下，服务级别诊断确定车轮速度传感器45中的三个故障，并且因此仅报告与由ABS模块2111生成的车轮速度传感器故障关联的三个DTC代码。
作为又一示例，考虑连接至RIO模块#1 431的常规网络通信总线44关闭/故障。在这种情况下，RIO模块#1 431为此将生成DTC。ABS 2111、PCM 2112和TCM 2113都在该通信总线44上，并且因此这些模块中的每一个也为此生成DTC。RIO模块#2 432和ADC 433需要与ABS模块2111通信，并且因此各自生成与ABS模块2111的通信已经丢失的DTC。类似地，IPC模块2114需要与ABS模块2111通信，并且因此生成与ABS模块2111的通信已经丢失的DTC。在面向信号的诊断结构中，将报告“通信总线关闭”DTC和“与ABS通信丢失”DTC，并且然后将需要对潜在故障或根本故障进行分析。相比之下，在面向服务的诊断架构中，可以在系统诊断层22和车辆诊断层23中执行DTC的服务级别分析，以确定通信总线关闭或故障是根本原因，并且因此仅报告“通信总线关闭”DTC。
图5示出了图2的分层诊断电气架构20如何可以以方向指示器特征的形式为车辆用户特征提供应用服务的示例。方向指示特征已经被分解为系统诊断层(或第二诊断层)22中的一个应用服务51，以及组件诊断层(或第一诊断层)21中的四个功能521、522、523、524。在所描述的示例中，车辆诊断层23和系统诊断层22两者都托管在CCP 41上，并且组件诊断层21托管在RIO 43上。四个功能组件或模块521、522、523、524各自托管在RIO 43中的不同一个上。四个功能组件521、522、523、524各自具有关联的诊断服务器5211、5221、5231、5241。
在所描述的示例中，四个功能521、522、523、524包括三个灯功能521、522、524和一个杆(stalk)功能523。功能521、522、523、524中的每一个从经由常规网络44(特别地在这种情况下为LIN)连接至其的相应的传感器531、532、533、534接收传感器数据。特别地，传感器包括与车辆上例如在车辆的前部或后部处或后视镜上的不同指示器灯关联的传感器。来自功能模块521、522、523、524中的每一个的数据经由以太网主干网络42传输至指示器服务模块51。
关于诊断能力，诊断服务器5211、5221、5231、5241中的每一个可以对接收到的传感器输出数据连同功能模块521、522、523、524的输入/输出连接执行诊断操作。诊断通知(例如以故障代码的形式)被传输至指示器应用服务51，并且特别地，服务51的本地诊断代理511对从功能模块521、522、523、524接收到的诊断通知以及指示器模块51的内部状态执行服务级别诊断。
如图5所示，非车载工程诊断测试器54连接至车辆诊断层23中的平台诊断服务模块231。由于本示例中仅存在一个应用服务——即指示器服务51——因此在车辆诊断层23中没有诊断通知的车辆或特征级别分类。指示器服务51的可用性存储在中央数据库232中。可以使工程测试器54知道指示器服务51，或者指示器服务51的可用性可以被发送至工程测试器54，使得与指示器服务51有关的诊断消息可以被发送至工程测试器54。特别地，本地诊断代理511可以基于其诊断操作生成组诊断通知。在所描述的示例中，使用UDS传输协议发送车辆外的工程测试器54与车辆上的平台服务模块231之间的诊断通信。车辆架构中的单独网关模块不是必需的。这是因为这样的网关功能可以作为平台诊断服务模块231的一部分提供。即，在面向服务的诊断通信与Do IP上的UDS(UDS on Do IP)之间转换诊断通信，使得测试器54与车辆架构20之间的成功诊断通信是可能的。
工程测试器54可以通过订阅存储在车载诊断注册表或中央数据库232中的所提供服务的诊断能力的最新列表来动态地发现指示器服务51。特别地，中央数据库232存储由诊断服务支持的故障列表、传感器读数等。如果指示器服务51的功能521、522、523、524之一被添加/除去/修改，则指示器服务51的诊断能力在中央注册表232中更新。例如，工程测试器54可以发送读取与指示器服务51关联的故障信息的请求。ECU 5211、5221、5231、5241以相关诊断对象例如故障代码/DTC形式的原始数据进行响应。然后，车载中央数据库232的诊断注册表可以用于解释DTC，并且将经解释的诊断对象发送回至诊断测试器54，使得在车辆外发送的诊断数据不需要被测试者解释。
基于组件的诊断允许检测传感器和致动器的物理故障。然而，它不允许确定接收到的传感器数据是否适合用于使用它的应用的目的。也就是说，即使传感器本身没有故障，接收到的数据也可能在对特定应用有用的范围之外。因此，可以通过引入对接收到的传感器数据的功能操作范围监测来改善服务的质量。
可以在组件级别即ECU级别监测传感器和致动器的物理故障。这包括物理I/O故障，例如短路故障或开路故障。在检测到这样的故障时，创建DTC日志。在服务级别，本地诊断代理2211可以执行传感器数据的功能操作范围监测。具体地，本地诊断代理2211可以评估在特定系统的给定操作状态下接收到的传感器数据的功能有效性，并且在给定上下文中融合来自其他源的接收到的数据。如果确定接收到的数据不适合目的，即使在组件级别没有检测到物理故障，本地诊断代理2211也将创建DTC日志并且生成事件通知。
一旦本地诊断代理2211生成这样的通知，它就通过车辆级别监督服务在车辆级别上针对车辆状态和功率模式进行评估。作为该评估的结果，如果必要，可以生成预测事件通知，即预测可能的传感器或致动器故障的事件通知。因此，诊断架构20不限于反应事件通知。
尽管图2的示例示出了本质上是层次化的具有多个诊断层的面向服务的诊断电气架构，但是在不同的示例中，本质上是非层次化的面向服务的诊断电气架构也是可能的。在这样的示例中，各个ECU可以广播或发布所提供的服务。例如，诸如外部诊断测试器的其他组件可以订阅特定的ECU以接收事件通知。
现在描述图1的非层次化的、面向信号的(即，UDS协议)架构10与面向服务的架构的非层次化的和层次化的变体(例如，图2的层次化的、面向服务的架构20)之间的差异。特别地，现在描述每个架构的诊断用例的设计、部署、运行时和更新阶段所涉及的步骤。
首先，描述了诊断设计阶段。对于UDS通信，需要UDS协议适配。这涉及识别特定系统的所有诊断用例。然后在用于诊断通信的UDS协议规范即如上所提及的ISO 14229-1之上定义制造商特定的规则和限制。注意，并非所有制造商特定的定制或扩展可以在UDS框架内是可行的。
对于面向服务的诊断(SoD)，需要进行SoD设计。对于平坦架构和分层架构两者，这涉及识别针对特定系统如针对UDS通信的所有诊断用例。然而，与UDS不同的是，设计了满足所有诊断用例的SoD服务，指定了服务提供者和消费者关系。然后选择满足所有识别的诊断用例的合适通信中间设备。特别地，可以选择合适的行业标准中间设备，例如SOME/IP(基于IP的可扩展的面向服务的中间设备)、REST(代表性状态传输)、DDS(数据分发服务)等。然后需要设计SoD服务接口。特别地，属性、方法、事件和字段是在所选择的中间设备之上指定的。对于分层的SoD架构，然后SoD服务接口在架构的各个诊断层例如上述系统和车辆层上进行实例化。
对于UDS和SoD通信两者，设计了诊断对象。在这两种情况下，识别系统的故障模式和故障原因。这可以使用故障模式影响分析(FMEA)或类似方法来实现。特别地，设计了诊断对象——以诊断故障代码(DTC)的形式——用于监测已识别的故障模式和故障原因。还设计了用于在发生故障时捕获环境条件的快照信息。创建用于配置ECU软件的诊断提取文件(DEXT)。还会创建用于配置诊断测试器的诊断描述文件(ODX)。
其次，描述了诊断部署阶段。对于UDS通信，ECU软件平台使用DEXT文件进行配置，并且诊断测试器使用ODX文件进行配置。外部过程确保DEXT文件和ODX文件的修订在车载ECU和诊断测试器之间兼容。
对于SoD通信，SoD服务接口部署在所选择的通信中间设备例如SOME/IP上。ECU软件平台使用DEXT文件和ODX文件进行配置。注意，这与UDS通信相反，在UDS通信中，ODX文件用于配置诊断测试器。对于平坦(非层次化)SoD，ECU ODX文件嵌入在ECU软件中，而对于分层(层次化)SoD，车辆ODX文件嵌入在架构的车辆诊断层中。这意味着无需使用ODX文件为(平坦和分层两者的)SoD通信配置外部的车外诊断测试器，这显著简化了需要例如由制造商管理的外部过程的复杂性。此外，对于车辆诊断层中ODX文件的分层SoD集中管理，进一步简化了过程和通信。
第三，考虑诊断运行时阶段。对于UDS通信，车外诊断测试器通过使用UDS协议与车辆内目标ECU或模块建立诊断通信。如果用于配置测试器的ODX文件与用于配置车辆中ECU软件堆栈的DEXT文件兼容，则此诊断通信成功。在示例中，车外诊断测试器发送请求消息，例如用于读取DTC信息的请求。车载目标ECU以UDS响应消息进行响应，UDS响应消息包括所请求的诊断对象，所述诊断对象具有使用“原始”值的适当静态配置的DTC。然后，诊断测试器通过使用利用诊断测试器配置的ODX文件来解释接收到的诊断对象的原始值。如果用于测试器的ODX文件与用于配置ECU软件的DEXT文件相同/兼容，则诊断可以正确解释来自ECU的响应。
对于SoD通信，车外诊断测试器通过使用SoD接口与车辆中的目标ECU或模块建立诊断通信。如果诊断测试器直接支持SoD接口，则此诊断通信成功。可替选地，诊断测试器使用UDS与车辆架构进行通信，并且车辆架构中的平台诊断服务模块在SoD与DoIP上的UDS之间执行转换，使得诊断测试器可以通过SoD接口与目标ECU成功通信。然后，诊断测试器能够经由SoD服务接口动态地发现或学习通过网络服务总线供应或提供的诊断服务。特别地，中央数据库维护包括供应的服务的列表的诊断服务注册表，并且诊断测试器订阅诊断服务注册表以动态地学习可用服务。注意，目标ECU还订阅了诊断服务注册表。由于ODX文件嵌入在车载架构中——特别地针对平坦架构的ECU软件中和针对分层架构的车辆诊断层中——然后目标ECU能够以诊断对象(DTC、事件、快照日期等)的解释值来响应诊断测试器，而不是需要在车辆外解释的诊断对象的原始值来响应诊断测试器。
最后，考虑诊断更新阶段。更新可以是例如新应用或诊断能力的形式。对于UDS通信和SoD通信两者，更新DEXT文件和ODX文件以反映诊断能力的变化。针对ECU软件配置发布了新版本的DEXT文件，并针对测试器配置发布了新版本的ODX文件。对于UDS配置和SoD配置两者，ECU软件使用新的DEXT文件进行重新配置。然而，与UDS通信不同，对于SoD通信，新的ODX也用于重新配置ECU软件。对于UDS通信，诊断测试器需要使用新的ODX文件通过使用外部过程进行重新配置。相比之下，对于SoD通信，不需要对外部诊断测试器进行这样的重新配置。对于UDS通信，如果测试器和目标ECU两者已静态更新以识别更改，目标ECU将在通过诊断测试器请求时支持新的诊断能力。相比之下，对于SoD通信，诊断测试器通过发现在更新的诊断服务注册表中供应的新诊断服务并订阅它们来动态地发现新的诊断能力。如上所述，如果诊断测试器支持SoD接口或者通过在车辆架构的平台诊断服务模块中执行UDS与SoD之间的转换，就可以成功建立诊断测试器与目标ECU之间的诊断通信。
图6概述了在车辆的诊断电气架构中提供诊断通信的方法60的步骤。该车辆具有包括用于托管诊断电气架构的多个车载计算设备的网络。车载计算设备包括CCP 41、多个RIO模块43或其他区域计算设备或域控制器，以及多个ECU或其他外围模块211。例如，诊断电气架构可以是图2的层次化架构20。可替选地，诊断电气架构可以是非层次化架构。架构20包括电子控制单元211，每个电子控制单元211具有诊断服务器模块212。架构20还包括服务接口模块221、231，其布置成允许车辆的电子控制单元211与网络服务总线42之间的诊断通信。在所描述的示例中，架构20包括系统层中的多个应用服务接口模块221，以及车辆层中的平台服务接口模块231。架构20还包括诊断服务注册模块222、232，其存储经由服务接口模块221、231供应的诊断服务的列表。
在步骤601处，诊断服务器模块212执行诊断任务以生成诊断对象数据。具体地，每个诊断服务器212具有多个相关联的诊断对象——其可以包括DTC、事件、数据ID(DID)和/或诊断控制例程——用于诊断监测与相应的ECU 211相关联的各种可能的故障模式、输入/输出/内部状态控制和/或模块识别。可以响应请求或其他事件生成特定诊断对象数据。诊断对象数据包括需要解释以识别相关联故障的原始数据或代码。例如，DEXT文件可以指定用于配置ECU诊断软件的配置参数以及由ECU软件支持的诊断对象。
在步骤602处，服务接口模块从ECU 211接收生成的诊断对象数据。特别地，在所描述的示例中，平台诊断服务模块231可以从多个ECU 211中的每一个中接收诊断对象数据。
在步骤603处，从诊断服务注册模块232中检索诊断服务数据。特别地，检索到的诊断服务数据包括所生成的诊断对象数据的诊断能力描述。例如，诊断服务数据可以包括诊断描述文件，例如ODX文件。
在步骤604处，诊断服务通知通过网络服务总线例如通过以太网骨干42进行传输。特别地，诊断服务通知基于所生成的诊断对象数据和诊断服务数据。也就是说，传输的诊断服务通知包括原始(非解释)诊断对象数据的解释值或数据。例如，诊断服务通知可以在车辆外传输至诊断测试器24，因此然后不需要解释从车辆架构20接收到的消息。
诊断服务通知可以是自主诊断服务通知，即发生事件/故障时自动生成。诊断服务通知也可以是对从车载或非车载诊断测试器接收的诊断请求的响应。
图7示出了车辆70，在所示实施方式中车辆70包括具有网络架构40(图8中未示出)并托管诊断电气架构20的汽车。
本发明的实施方式有利的是它们在车辆电气网络架构中提供了面向服务的诊断通信。这与其中使用面向信号的诊断通信——例如，使用UDS协议——的已知系统形成对照。本发明的面向服务的诊断通信允许将诊断任务作为跨车辆服务总线的服务而供应至例如车辆外的诊断测试器或者供应至作为车辆网络架构的一部分的其他模块。特别地，面向服务的诊断通信允许将经解释的诊断消息而不是原始诊断数据例如一个或更多个DTC传送至例如外部诊断测试器，原始诊断数据然后需要在车辆外进行解释。
本发明的实施方式特别地有利的是它们使用面向服务的架构中间设备独立地进行诊断通信。这允许提供可扩展且灵活的车载服务诊断接口。特别地，ECU诊断能力的更新不需要重新刷新ECU。此外，这允许由其他组件(例如，外部诊断测试器)动态发现诊断服务，使得无需专门配置这些组件以与任何ECU诊断更新兼容。
已知系统不提供这样的能力，至少不提供最大程度的能力。一些已知系统为面向服务的架构供应中间设备支持；然而，这些系统仅在ECU的基本软件组件内供应对UDS诊断的支持。因此，已知系统继承了UDS协议的限制。例如，在一些已知系统中，ECU的诊断能力需要在ECU的设计和开发阶段进行静态配置。也就是说，每次ECU的诊断能力发生变化时，ECU的基本软件层需要进行静态重新配置和重新刷新。一些已知系统可以提供ECU基本软件层的一定程度的动态配置，例如可以提供用于更新某些软件包的功能，而无需重新刷新整个ECU。在这样的情况下，各个软件包被聚集在一起并且具有它们自己的诊断地址，这些地址用于经由诊断管理器组件访问诊断功能或软件更新，其中，该组件能够使用另一文件对每个软件包进行配置。然而，这些已知系统均没有提供UDS供应的服务之外的能力/灵活性。
本发明的实施方式有利的是组件例如外部诊断测试器可以订阅特定服务，使得可以动态地学习对服务的诊断更新。特别地，本发明有利地允许服务基于事件触发例如服务的诊断能力的更新来生成事件通知或向服务的所有订阅者发布事件通知。此外，事件通知可以有利地被提供向服务订阅者的递送保证。
本发明的实施方式有利的是，从诊断访问的角度来看，它们通过经由服务接口模块引入抽象层提供了外部连接模块即诊断测试器与车辆核心模块即ECU之间的逻辑分隔和物理分隔。这提高了安全性，并且使诊断架构不易受到网络攻击。这与p2p诊断架构形成对照，在p2p诊断架构中，外部诊断测试器可以建立与车载ECU的直接通信路径。
本发明的实施方式有利的是它们提供了动态诊断资源冲突管理。具体地，本发明的实施方式有利地允许同时访问多个不同的诊断测试器，例如，立法扫描工具(legislative scan tool)、SOTA事件、OBD扫描工具、保险加密狗等。这与一些已知系统形成对照，这些已知系统被限制为允许通过网关模块一次访问一个诊断测试器，即使不同的测试器需要访问不同的系统域。
参照图8，示出了上述车载计算设备800的简化示例。车载计算设备800可以包括具有一个或更多个电子处理器(例如，微处理器、微控制器、专用集成电路(ASIC)等)的控制单元或计算设备，并且可以包括单个控制单元或计算设备，或者可替选地，车载计算设备800或每个车载计算设备800的不同功能可以实施或托管在不同的控制单元或计算设备中。如本文中所使用的，术语“控制器”、“控制单元”或“计算设备”将被理解为包括单个控制器、控制单元或计算设备，以及多个控制器、控制单元或计算设备，它们共同操作以提供所需的控制功能。可以提供一组指令，该组指令在被执行时使车载计算设备800实现本文中所述的控制技术(包括本文中所述的方法所需的部分或全部功能)。该组指令可以嵌入车载计算设备800的所述一个或更多个电子处理器中；或者可替选地，该组指令可以作为软件提供以在车载计算设备800中执行。第一控制器或控制单元可以在一个或更多个处理器上运行的软件中实现。一个或更多个其他控制器或控制单元可以在一个或更多个处理器——可选地，与第一控制器或控制单元相同的所述一个或更多个处理器——上运行的软件中实现。其他布置也是可用的。
在图8所示的示例中，车载计算设备800包括至少一个电子处理器820，所述至少一个电子处理器820具有用于接收一个或更多个(输入信号)的一个或更多个电输入822，以及用于输出一个或更多个(输出信号)的一个或更多个电输出824。车载计算设备800还包括电耦接至所述至少一个电子处理器820并且其中存储有指令840的至少一个存储器设备830。所述至少一个电子处理器820被配置成访问所述至少一个存储器设备830并执行在其上的指令840。
电子处理器820或每个电子处理器820可以包括被配置成执行电子指令的任何合适的电子处理器(例如，微处理器、微控制器、ASIC等)。电子存储器设备830或每个电子存储器设备830可以包括任何适当的存储器设备，并且可以存储各种数据、信息、阈值、查找表或其他数据结构、和/或其中或其上的指令。在实施方式中，存储器设备830具有用于存储在其中或其上的软件、固件、程序、算法、脚本、应用等的信息和指令，这些信息和指令可以控制本文中所述的方法的全部或部分。处理器或每个电子处理器820可以访问存储器设备830，并且执行和/或使用该指令和信息或那些指令和信息以实现或执行本文中所述的功能和方法的部分或全部。
所述至少一个存储器设备830可以包括计算机可读存储介质(例如非暂态或非瞬态存储介质)，该计算机可读存储介质可以包括用于存储由机器或电子处理器/计算设备可读的形式的信息的任何机制，该计算机可读存储介质包括但不限于：磁性存储介质(例如软盘)；光存储介质(例如CD-ROM)；磁光存储介质；只读存储器(ROM)；随机存取存储器(RAM)；可擦除可编程存储器(例如EPROM和EEPROM)；闪速存储器；或用于存储这样的信息/指令的电的或其他类型的介质。
已经描述了示例车载计算设备800，其包括至少一个电子处理器820，电子处理器820被配置成执行存储在至少一个存储器设备830中的电子指令，电子指令在被执行时使电子处理器820执行如上文中所述的方法。然而，应当理解，本发明的实施方式可以用硬件、软件或硬件和软件的组合的任何适当形式实现。例如，可以构想，本发明不限于通过可编程处理设备的方式来实现，本发明的功能和/或方法步骤中的至少一些功能和/或方法步骤并且在一些实施方式中全部功能和/或方法步骤可以同样通过不可编程硬件的方式来实现，例如通过不可编程ASIC、布尔逻辑电路等来实现。
应当理解，在不脱离本申请的范围的情况下，可以对本发明进行各种改变和修改。例如，本说明书中公开的所有特征(包括任何所附权利要求、摘要和附图)，和/或如此公开的任何方法或过程的所有步骤可以以任何组合进行组合，但至少一些这样的特征和/或步骤相互排斥的组合除外。
除非另有明确说明，否则本说明书中公开的每个特征(包括任何所附权利要求、摘要和附图)可以由具有相同、等效或类似目的的可替选的特征替代。因此，除非另有明确说明，否则公开的每个特征仅为等效或类似特征的通用系列的一个示例。
本发明不限于任何前述实施方式的细节。本发明延伸至本说明书(包括任何所附权利要求、摘要和附图)中公开的特征的任何新颖的一个或任何新颖的组合，或者不限于如此公开的任何方法或过程的步骤的任何新颖的一个或任何新颖的组合。权利要求不应该被理解为仅仅涵盖前述实施方式，而且还应涵盖落入权利要求的范围内的任何实施方式。

Claims (13)

1.一种用于车辆的诊断电气架构，所述车辆包括用于托管所述诊断电气架构的多个车载计算设备，并且所述诊断电气架构包括：
一个或更多个电子控制单元，每个所述电子控制单元包括诊断服务器模块，所述诊断服务器模块被布置成执行诊断任务以生成诊断对象数据；
服务接口模块，所述服务接口模块被布置成允许所述一个或更多个电子控制单元与所述车辆的网络服务总线之间的诊断通信，所述服务接口模块被布置成接收所生成的诊断对象数据；以及
诊断服务注册模块，所述诊断服务注册模块被布置成存储指示由所述服务接口模块提供的诊断服务的诊断服务数据，所述诊断服务数据包括所生成的诊断对象数据的诊断能力描述，
其中，所述服务接口模块被布置成通过所述网络服务总线传送诊断服务通知，所述诊断服务通知是基于所生成的诊断对象数据和从所述诊断服务注册表检索到的所述诊断服务数据。
2.根据权利要求1所述的诊断电气架构，其中，所述诊断服务通知是响应于由所述服务接口模块提供的诊断能力的变化而生成的；
可选地，所述诊断能力的变化是由所述一个或更多个电子控制单元执行的诊断任务的添加或移除引起的；
可选地，所述诊断能力的变化是由与所述服务接口模块相关联的电子控制单元的添加或移除引起的。
3.根据任一前述权利要求所述的诊断电气架构，其中，所述诊断服务通知是响应于由所述服务接口模块接收到的对诊断能力的请求而生成的；
可选地，所述对诊断能力的请求是从所述车辆外的诊断测试器接收的。
4.根据任一前述权利要求所述的诊断电气架构，其中，所生成的服务通知在所述车辆外传送。
5.根据任一前述权利要求所述的诊断电气架构，其中，所生成的诊断能力通知用于更新所述诊断注册模块。
6.根据任一前述权利要求所述的诊断电气架构，其中，所述服务接口模块部署在所述车载计算设备中的一个或更多个车载计算设备上的通信中间设备上；可选地，所述通信中间设备是以下之一：
SOME/IP(基于IP的可扩展的面向服务的中间设备)；
REST(表征状态转移)；以及
DDS(数据分发服务)。
7.根据任一前述权利要求所述的诊断电气架构，其中，所述车辆服务总线包括以太网骨干网络；可选地，所述服务接口模块直接连接至所述以太网骨干网络。
8.根据任一前述权利要求所述的诊断电气架构，其中，所述诊断服务注册模块被布置成允许车载模块和非车载模块订阅所述诊断服务注册模块，使得所述车载模块和非车载模块动态地学习由所述服务接口模块提供的诊断服务。
9.根据任一前述权利要求所述的诊断电气架构，所述诊断电气架构被布置成提供统一诊断服务(UDS)协议通信与面向服务的诊断通信之间的转换。
10.根据任一前述权利要求所述的诊断电气架构，其中，所述诊断电气架构是具有组件诊断层和至少一个监督诊断层的层次化架构，所述组件诊断层包括所述一个或更多个电子单元；
可选地，所述至少一个监督诊断层包括所述服务接口模块；
可选地，所述至少一个监督诊断层包括所述诊断服务注册模块；
可选地，所述至少一个监督诊断层包括系统诊断层和车辆诊断层，所述车辆诊断层相比于所述系统诊断层处于所述架构的更高层级，所述车辆诊断层包括所述服务接口模块，并且所述系统诊断层包括应用服务模块，所述应用服务模块包括本地诊断代理，所述本地诊断代理被布置成汇总从所述电子控制单元接收的所生成的诊断服务通知以生成监督级诊断服务通知；
可选地，所述监督级诊断服务通知用于更新所述诊断服务注册模块。
11.一种包括网络架构的车辆，所述网络架构具有多个计算设备并且托管任一前述权利要求所述的诊断电气架构。
12.一种在车辆的诊断电气架构中提供诊断通信的方法，所述车辆包括用于托管所述诊断电气架构的多个车载计算设备，所述诊断电气架构包括：
一个或更多个电子控制单元，每个所述电子控制单元包括诊断服务器模块；
服务接口模块，所述服务接口模块被布置成允许所述一个或更多个电子控制单元与所述车辆的网络服务总线之间的诊断通信；以及
诊断服务注册模块，
所述方法包括：
由所述诊断服务器模块执行诊断任务以生成诊断对象数据；
将所生成的诊断对象数据接收到所述服务接口模块中；
从所述诊断服务注册模块检索诊断服务数据，所述诊断服务数据包括所生成的诊断对象数据的诊断能力描述；以及
通过所述网络服务总线传送诊断服务通知，所述诊断服务通知是基于所生成的诊断对象数据和所述诊断服务数据。
13.一种非暂态计算机可读存储介质，其上存储有指令，所述指令在由一个或更多个处理器执行时使所述一个或更多个处理器执行权利要求12所述的方法。
CN202080061635.6A 2019-09-02 2020-08-27 用于面向服务的车辆诊断的电气架构 Pending CN114341758A (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB1912568.1 2019-09-02
GB1912568.1A GB2595430B (en) 2019-09-02 2019-09-02 Electrical architecture for service-oriented vehicle diagnostics
PCT/EP2020/073946 WO2021043660A1 (en) 2019-09-02 2020-08-27 Electrical architecture for service-oriented vehicle diagnostics

Publications (1)

Publication Number Publication Date
CN114341758A true CN114341758A (zh) 2022-04-12

Family

ID=68207248

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202080061635.6A Pending CN114341758A (zh) 2019-09-02 2020-08-27 用于面向服务的车辆诊断的电气架构

Country Status (6)

Country Link
US (1) US20220335754A1 (zh)
EP (1) EP4026104A1 (zh)
JP (1) JP2022546107A (zh)
CN (1) CN114341758A (zh)
GB (1) GB2595430B (zh)
WO (1) WO2021043660A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220365874A1 (en) * 2019-03-25 2022-11-17 Aurora Labs Ltd. Identifying software dependencies using controller code models
CN116088485A (zh) * 2023-04-06 2023-05-09 小米汽车科技有限公司 车辆故障数据采集系统、方法及车辆

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11794758B2 (en) * 2020-11-30 2023-10-24 GM Global Technology Operations LLC Selective health information reporting systems including integrated diagnostic models providing least and most possible cause information
CN113132472B (zh) * 2021-04-07 2022-08-02 武汉光庭信息技术股份有限公司 车载T-Box的RESTful Web动态服务注册方法
CN113204226B (zh) * 2021-04-25 2022-12-09 重庆长安汽车股份有限公司 整车诊断系统及方法
GB2609392A (en) * 2021-07-01 2023-02-08 Aptiv Tech Ltd Method of configuring an automotive controller, automotive controller, and automotive controller system
CN114756258B (zh) * 2022-01-04 2023-03-24 广州汽车集团股份有限公司 一种基于odx的ecu软件刷新方法与系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6330499B1 (en) * 1999-07-21 2001-12-11 International Business Machines Corporation System and method for vehicle diagnostics and health monitoring
US6766230B1 (en) * 2000-11-09 2004-07-20 The Ohio State University Model-based fault detection and isolation system and method
US20090295559A1 (en) * 2008-06-02 2009-12-03 Gm Global Technology Operations, Inc. Integrated hierarchical process for fault detection and isolation
US20180182184A1 (en) * 2016-12-22 2018-06-28 Dr. Ing. H.C. F. Porsche Aktiengesellschaft Method and system for the diagnosis or configuration of a vehicle
US20180232959A1 (en) * 2017-02-15 2018-08-16 Ford Global Technologies, Llc Enhanced central gateway for vehicle networking

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6330499B1 (en) * 1999-07-21 2001-12-11 International Business Machines Corporation System and method for vehicle diagnostics and health monitoring
US6766230B1 (en) * 2000-11-09 2004-07-20 The Ohio State University Model-based fault detection and isolation system and method
US20090295559A1 (en) * 2008-06-02 2009-12-03 Gm Global Technology Operations, Inc. Integrated hierarchical process for fault detection and isolation
US20180182184A1 (en) * 2016-12-22 2018-06-28 Dr. Ing. H.C. F. Porsche Aktiengesellschaft Method and system for the diagnosis or configuration of a vehicle
CN108227674A (zh) * 2016-12-22 2018-06-29 保时捷股份公司 用于车辆的诊断或配置的方法和系统
US20180232959A1 (en) * 2017-02-15 2018-08-16 Ford Global Technologies, Llc Enhanced central gateway for vehicle networking

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220365874A1 (en) * 2019-03-25 2022-11-17 Aurora Labs Ltd. Identifying software dependencies using controller code models
US11741280B2 (en) * 2019-03-25 2023-08-29 Aurora Labs Ltd. Identifying software dependencies using controller code models
CN116088485A (zh) * 2023-04-06 2023-05-09 小米汽车科技有限公司 车辆故障数据采集系统、方法及车辆

Also Published As

Publication number Publication date
JP2022546107A (ja) 2022-11-02
WO2021043660A1 (en) 2021-03-11
EP4026104A1 (en) 2022-07-13
GB2595430B (en) 2024-04-17
GB201912568D0 (en) 2019-10-16
US20220335754A1 (en) 2022-10-20
GB2595430A (en) 2021-12-01

Similar Documents

Publication Publication Date Title
US20220335754A1 (en) Electrical architecture for service-oriented vehicle diagnostics
US11842582B2 (en) Layered electrical architecture for vehicle diagnostics
US7729827B2 (en) Vehicle control system
US7295903B2 (en) Device and method for on-board diagnosis based on a model
CN108351822A (zh) 处理装置及车辆控制系统
JP5319534B2 (ja) 障害管理方法、および障害管理のための装置
WO2021113305A1 (en) Master agent and distributed agent architecture for vehicles
Navet et al. A review of embedded automotive protocols
CN114375270B (zh) 用于车辆的分布式诊断架构
Kimm et al. Integrated fault tolerant system for automotive bus networks
KR102446579B1 (ko) 차량용 데이터 교환 장치와 데이터 교환 방법, 차량의 차량 부품용 장치와 방법 및 컴퓨터 프로그램
KR20190000137A (ko) 차량 제어기 고장 진단 또는 동작 감시 방법 및 장치
EP2149823A1 (fr) Système aéronautique embarqué à reconfiguration dynamique, procédé associé et aéronef embarquant un tel système
WO2022218401A1 (zh) 车辆故障诊断方法、车载诊断装置
Suwatthikul Fault detection and diagnosis for in-vehicle networks
JP2019146145A (ja) 通信装置、通信方法及びプログラム
CN112511396A (zh) 一种整车通信监控方法及装置
WO2020049871A1 (ja) 車両用通信装置
US11764995B2 (en) Transceiver device
CN115617558A (zh) 车辆诊断系统、方法、存储介质以及车辆
Ajin et al. Study of security and effectiveness of DoIP in vehicle networks
WO2022255069A1 (ja) 車載通信装置、車載中継装置、車載通信システム及び通信方法
Chaaban et al. Simulation of a steer-by-wire system using FlexRay-based ECU network
Sivaram et al. AUTOSAR: In-vehicle Standardization with Certainty of Operations towards Globalization
US20220286473A1 (en) Anomaly detection system and anomaly detection method

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination