CN113377393B - 一种车载系统主节点的诊断刷新系统及方法 - Google Patents

Abstract

本发明涉及车载系统主节点的诊断刷新系统及方法。车载系统主节点的诊断刷新系统包括：第一核，在第一核上运行有第一操作系统，并且第一核包括用于产生远程刷新请求数据的远程刷新模块；诊断记录口DLC，其用于产生DLC刷新请求数据和/或诊断请求数据；以及第二核，在第二核上运行有第二操作系统，并且第二核包括用于处理远程刷新请求数据和/或DLC刷新请求数据和/或诊断请求数据的数据处理模块。车载系统主节点的刷新方法包括以下步骤：接收来自诊断记录口的DLC刷新请求数据和/或来自第一核中的远程刷新模块的远程刷新请求数据；对DLC刷新请求数据和远程刷新请求数据进行处理；以及将处理后的远程刷新请求数据发送至第一核中的操作系统接口模块。

Description

一种车载系统主节点的诊断刷新系统及方法

技术领域

本发明涉及车载系统诊断刷新领域。具体而言，本发明涉及一种车载系统主节点的诊断刷新系统及方法。

背景技术

随着汽车零部件应用技术向智能网联化发展，特别地，智能驾驶系统、软件OTA更新以及应用软件持续集成很快将成为车辆的标配功能。这使得车载模块系统日益复杂，车辆搭载的各类软件数量倍增，从而对内核芯片运算能力及控制实时性提出极高要求，使得以芯片内核为载体的嵌入式系统软件开发面临极大挑战。

为了满足新挑战，将由计算能力超强的微处理器作为传统汽车电控主流微控制器补充来构成的高性能异构多核芯片SOC技术应用于汽车领域成为大势所趋。该类SOC芯片和智能手机或PC中使用的微处理器非常相似，这需要应用一种与传统汽车电子不同的基于POSIX接口的操作系统环境。

考虑到车载软件更新核心技术OTA（Over-the-Air Technology）空中下载技术的应用，使得联网汽车用户只需在自己的车机屏幕或是手机上操作就能实现相关系统的升级。鉴于OTA技术具备降低售后服务成本，快速修复系统缺陷，软件迭代迅速等优点，各大整车厂及主流供应商纷纷加大了对OTA技术的研发投入并陆续推出量产车型。

在现有的方案中，远程刷新主节点主要有两种选择方案：一种信息娱乐系统模块刷新方案，另一种是中央网关刷新方案。前者基于带文件系统且符合POSIX接口的Linux开发，在自身软件升级方面有显著优势，但在系统实时性及网络安全方面存在极大风险；后者作为中央网关，基于RTOS开发，实时性及网络安全可以满足要求，但自身软件升级不容易实现。

发明内容

因此，需要一种能够同时适用于Linux系统以及RTOS系统的基于多核异构架构的车载系统主节点的诊断刷新系统及方法。

为实现以上目的的一个或多个，本发明提供以下技术方案。

按照本发明的第一方面，提供一种车载系统主节点的诊断刷新系统，其包括：第一核，在第一核上运行有第一操作系统，并第一核包括用于产生远程刷新请求数据的远程刷新模块；诊断记录口DLC，其用于产生DLC刷新请求数据和/或诊断请求数据；以及第二核，在第二核上运行有第二操作系统，并且第二核包括用于处理远程刷新请求数据和/或DLC刷新请求数据和/或诊断请求数据的第二数据处理模块。

根据本发明一实施例的诊断刷新系统，其还包括：交换机，其配置成通信地连接到第一核、第二核以及诊断记录口，并且配置成用于第一核、第二核以及诊断记录口之间的信号传递。

根据本发明一实施例或以上任一实施例的诊断刷新系统，其中，第一核还包括：用于处理远程刷新请求数据和/或DLC刷新请求数据和/或诊断请求数据的第一数据处理模块。

根据本发明一实施例或以上任一实施例的诊断刷新系统，其中：第一操作系统是Linux操作系统，以及第二操作系统是实时操作系统RTOS。

根据本发明一实施例或以上任一实施例的诊断刷新系统，第一核是Cortex-A核，以及第二核是Cortex-M核或Cortex-R核。

根据本发明一实施例或以上任一实施例的诊断刷新系统，其中：诊断请求数据包括针对第一核的第一诊断请求数据以及针对第二核的第二诊断请求数据。

按照本发明的第二方面，提供一种车载系统主节点的刷新方法，其包括以下步骤：接收来自诊断记录口的DLC刷新请求数据和/或来自第一核中的远程刷新模块的远程刷新请求数据；对DLC刷新请求数据和/或远程刷新请求数据进行处理；以及将处理后的DLC刷新请求数据和/或远程刷新请求数据发送至第一核中的操作系统接口模块。

根据本发明一实施例的车载模块的刷新方法，其中，接收和发送的步骤经由交换机来实现。

按照本发明的第三方面，提供一种车载系统主节点的诊断方法，其包括以下步骤：接收来自诊断记录口的诊断请求数据；对诊断请求数据进行处理；以及将处理后的诊断请求数据发送至第一核中的操作系统接口模块和/或第二核中的诊断通讯管理器模块。

根据本发明一实施例的诊断方法，其中，接收和发送的步骤经由交换机来实现。

根据本发明一实施例或以上任一实施例的诊断方法，其中：诊断请求数据包括针对第一核的第一诊断请求数据以及针对第二核的第二诊断请求数据。

以下是本公开中涉及的英文缩写机器释义的参考列表：

附图说明

本发明的上述和/或其它方面和优点将通过以下结合附图的各个方面的描述变得更加清晰和更容易理解，附图中相同或相似的单元采用相同的标号表示。附图包括：

图1为根据本发明一实施例的车载系统主节点的诊断刷新系统的示意性框图；

图2为根据本发明一实施方式的车载系统主节点的诊断刷新系统的框图；

图3为根据本发明一实施例的刷新方法的流程图；

图4为根据本发明一实施方式的针对第一核的DLC刷新请求数据或DLC诊断请求数据的信号流向图；

图5为根据本发明一实施方式的针对第一核的远程刷新请求数据的信号流向图；

图6为根据本发明一实施例的诊断方法的流程图；以及

图7为根据本发明一实施方式的针对第二核的DLC诊断请求数据的信号流向图。

具体实施方式

在本说明书中，参照其中图示了本发明示意性实施例的附图更为全面地说明本发明。但本发明可以按不同形式来实现，而不应解读为仅限于本文给出的各实施例。给出的各实施例旨在使本文的披露全面完整，以将本发明的保护范围更为全面地传达给本领域技术人员。

诸如“包含”和“包括”之类的用语表示除了具有在说明书和权利要求书中有直接和明确表述的单元和步骤以外，本发明的技术方案也不排除具有未被直接或明确表述的其它单元和步骤的情形。诸如“第一”和“第二”之类的用语并不表示单元在时间、空间、大小等方面的顺序而仅仅是作区分各单元之用。此外，需要注意的是，以单数形式描述或没有特意指出只能为单数的名词，基于其复数形式的实施例也在本公开的范围内。

下文参考根据本发明实施例的方法和系统的流程图说明、框图和/或流程图来描述本发明。将理解这些流程图说明和/或框图的每个框、以及流程图说明和/或框图的组合可以由计算机程序指令来实现。可以将这些计算机程序指令提供给通用计算机、专用计算机或其它可编程数据处理设备的处理器以构成机器，以便由计算机或其它可编程数据处理设备的处理器执行的这些指令创建用于实施这些流程图和/或框和/或一个或多个流程框图中指定的功能/操作的部件。

可以将这些计算机程序指令加载到计算机或其它可编程数据处理器上以使一系列的操作步骤在计算机或其它可编程处理器上执行，以便构成计算机实现的进程，以使计算机或其它可编程数据处理器上执行的这些指令提供用于实施此流程图和/或框图的一个或多个框中指定的功能或操作的步骤。还应该注意在一些备选实现中，框中所示的功能/操作可以不按流程图所示的次序来发生。例如，依次示出的两个框S101和S102实际可以基本同时地执行或这些框有时可以按逆序执行，具体取决于所涉及的功能/操作。

为解决上述车载系统中央网关的刷新及诊断问题，本发明提出一种基于异构多核架构的主节点中央网关的诊断刷新系统和方法。该方法以异构多核芯片SOC为载体设计远程刷新主节点中央网关，该芯片SOC可以是ARM架构，异构多核，由多个M(R)核和A核构成。同时，本发明设计了两套诊断ID，一套诊断ID可以应用于可搭载实时操作系统RTOS M(R)核，主要实现自身诊断服务；并且，实时操作系统RTOS M(R)核上还实现了对实时性、安全性的要求很高的诊断路由、刷新路由及报文过滤等功能。另一套诊断ID可以应用于可搭载带文件系统的Linux系统A核，主要实现OTA主节点刷新功能，包括自身软件升级及其他模块软件升级等,该方法兼具控制实时性、网络安全可靠性、刷新方案容易实现等优点。

本发明为整车实现OTA功能奠定基础，通过在线更新车上电子模块软件，降低软件更新成本。

本发明的车载系统主节点的刷新方法兼容通过DLC口进行的产线售后刷新和OTA远程刷新两种方式。在通过DLC口进行的产线售后刷新中，刷新数据以DOIP协议格式经过交换机转发到运行在RTOS环境下的AUTOSAR协议栈SoAd、DOIP、PDUR等模块，经过所述模块处理之后再经过交换机以AUTOSAR Eth格式数据转发到运行在Linux下的UDSOnETH Server模块，经处理成UDS格式数据，继而传递给Posix Flash Master软件的UDS server模块处理。主要有两种处理方式，一种是在诊断过程中根据诊断请求数据对诊断服务作出相应反馈，另外一种是在刷新过程中将刷新数据交由Posix Flash Master来进行刷新。

现在参考图1，图1为根据本发明一实施例的车载系统主节点的诊断刷新系统100的示意性框图。车载系统主节点的诊断刷新系统100包括第一核110、第二核120以及诊断记录口130。

在第一核110（例如，Cortex-A核）上运行有第一操作系统（例如，Linux操作系统），并且第一核110可以包括用于产生远程刷新请求数据的远程刷新模块1102。在一个实施例中，第一核还可以包括用于处理远程刷新请求数据和/或DLC刷新请求数据和/或诊断请求数据的第一数据处理模块（图1中未示出）。

诊断记录口DLC 130用于产生DLC刷新请求数据和/或诊断请求数据。其中诊断请求数据可以包括针对第一核的第一诊断请求数据以及针对第二核的第二诊断请求数据。

在第二核120（例如，Cortex-M核、Cortex-R核等）上运行有第二操作系统（例如，实时操作系统RTOS），并且第二核包括用于处理远程刷新请求数据和/或DLC刷新请求数据和/或诊断请求数据的第二数据处理模块1202。

在一个实施例中车载系统主节点的诊断刷新系统100还包括交换机140，其配置成通信地连接到第一核、第二核以及诊断记录口，并且配置成用于第一核、第二核以及诊断记录口之间的信号传递。

在一种实施方式中，车载系统主节点的诊断刷新系统200如图2中所示。图2提供了一种基于异构多核架构的车载系统主节点的诊断刷新系统200，其中示出一个在第二核220（如M核或R核）上运行的嵌入式平台实时操作系统RTOS和一个在第一核210（如A核）上运行的Linux操作系统，一个诊断记录口DLC 230以及用于RTOS、Linux与DLC互相通讯的车载以太网交换机芯片240。

其中，DLC 230刷新主要用于工厂产线刷新以及售后刷新。

RTOS的软件架构中由上至下分别为：PDUR模块2201，其用于在接收PDU后，通过查询路由表得到对应模块，然后将PDU转发到对应模块；DOIP模块2202，其用于建立基于以太网的DOIP连接以及DOIP报文的封装及拆解包；SoAd模块2203，其用于与对端建立基于以太网的socket连接以及PDU Header的添加及去除，另外，其利用PDU Header来实现UDSOnETH机制。其中。SoAd,DOIP,PDUR等模块可以是AUTOSAR协议栈。

Linux的软件架构中由左上至右下分别为POSIX FLASH MASTER模块2104，其提供刷新片外NOR FLASH，EMMC等服务，同时提供相关软件管理服务；其中的UDS Server模块2107负责解析UDS信息、执行相应UDS服务以及给出对应的UDS响应；UDSonETH Server模块2108，其用于解析UDSonETH报文，主要解析该报文的PDU Header，实现UDSonETH机制；OTAMaster模块2102，其用于执行车载远程刷新主节点的相关逻辑；DOIP Client模块2106，其用于模拟DOIP Tester，主动发起与RTOS中的DOIP模块2202的DOIP连接以及DOIP报文的封装及拆解包。其中，AUTOSAR Eth格式数据转发到运行在Linux下的UDSOnETH Server模块处理成UDS格式数据，传递给Posix Flash Master软件的UDS server模块处理, 处理结果主要有两种，一种是根据诊断请求数据对诊断服务作出相应反馈，另外一种是将刷新数据交由Posix Flash Master来进行刷新。

图3示出了根据本发明一实施例的车载系统主节点的刷新方法300的流程图。刷新方法300可以包括接收来自诊断记录口的DLC刷新请求数据和/或来自第一核中的远程刷新模块的远程刷新请求数据（S301）。其中，远程刷新请求可能最初地由用户从手机发起或是通过车载屏幕或按钮发起。刷新方法300还可以包括对DLC刷新请求数据和所述远程刷新请求数据进行处理（S302），处理操作可以包括例如去除报头、添加报头、转发等。刷新方法300还可以包括将处理后的远程刷新请求数据发送至所述第一核中的操作系统接口模块（S303）。通常，接收和发送数据的步骤可以经由交换机来实现，交换机可以是交换机芯片的形式。

图4示出了根据本发明一实施方式的针对第一核的DLC刷新请求数据的信号流向图。以下参考图4以及图2来具体说明本发明一实施方式的针对第一核的DLC刷新的方法。如图4中所示，在图4的上半部分，DLC刷新请求数据先从DLC 230通过DoIP Request报文①发送到交换机。经交换机转发后，DoIP Request报文③被发送RTOS中的SoAd模块2203。SoAd模块2203将TCP/IP Payload⑤发送到DOIP模块2202。DOIP模块2202将去除DOIP Header后的DOIP Payload⑦发送到PDUR模块2201。PDUR模块2201再将此PDU⑨转发到SoAd模块2203。SoAd模块2203将添加对应PDU Header后的PDU⑪发送到交换机240。交换机240随后将此PDU⑬转发到Linux中。UDSonETH Server模块2108将去除PDU Header后的PDU Payload⑮发送到UDS Server模块2107。

图4的下半部分示出DLC刷新响应的过程。DLC刷新响应数据先从UDS Server模块2107通过UDS报文⑯发送到UDSonETH Server模块2108。UDSonETH Server模块2108将添加PDU Header后的PDU⑭发送到交换机240。交换机240将该PDU⑫转发到SoAd模块2203。SoAd模块2203将去除PDU Header后的PDU Payload⑩发送到PDUR模块2201。PDUR模块2201将该PDU Payload⑧转发到DOIP模块。DOIP模块2202将添加DOIP Header后的DOIP PDU⑥发送到SoAd模块2203。SoAd模块2203将添加对应PDU Header后的PDU④发送到交换机240。交换机240将此PDU②转发到DLC 230。

图5示出了根据本发明一实施方式的针对第一核的远程刷新请求数据的信号流向图。以下参考图5以及图2来具体说明本发明一实施方式的针对第一核的远程刷新的方法。如图5中所示，在图5的上半部分，远程刷新请求数据[3]从OTA MASTER 2102发送到UDSClient模块2105，随后UDS Client模块2105发送UDS PDU⑰到DOIP Client模块2106。DOIPClient 2106模块将添加DOIP Header后的DOIP PDU⑲发送到交换机240。经转发后，DoIPRequest报文③被发送RTOS中的SoAd模块2203。SoAd模块2203将TCP/IP Payload⑤发送到DOIP模块2202。DOIP模块2202将去除DOIP Header后的DOIP Payload⑦发送到PDUR模块2201。PDUR模块2201将此PDU⑨转发到SoAd模块2203。SoAd模块2203将添加对应PDU Header后的PDU⑪发送到交换机240。交换机240将此PDU⑬转发到Linux中。UDSonETH Server模块2108将去除PDU Header后的PDU Payload⑮发送到UDS Server模块2107。

在图5的下半部分，示出远程刷新响应数据从UDS Server 2107发出，以UDS报文⑯的形式发送到UDSonETH Server模块2108。UDSonETH Server模块2108将添加PDU Header后的PDU⑭发送到交换机240。交换机240将该PDU⑫转发到SoAd模块2203。SoAd模块2203将去除PDU Header后的PDU Payload⑩发送到PDUR模块2201。PDUR模块2201将该PDU Payload⑧转发到DOIP模块2202。DOIP模块2202将添加DOIP Header后的DOIP PDU⑥发送到SoAd模块2203。SoAd模块2203将添加对应PDU Header后的PDU④发送到交换机240。交换机240将此PDU⑳转发到DOIP Client模块2106。DOIP Client模块2106去除DOIP Header后，将DOIPPayload数据⑱发送到UDS Client模块2105处理后的数据[4]反馈给OTA MASTER模块2102。

本发明的刷新方法首次基于异构多核架构内核实现兼容产线售后（DLC）及远程刷新的方案，该方案的实施使得产线设备及流程可以保证各种场景下应用一套刷新策略，降低了变更及维护成本。

图6示出了根据本发明一实施例的车载系统主节点的诊断方法400的流程图。诊断方法400可以包括接收来自诊断记录口的诊断请求数据（S401）。诊断请求数据通常可以来自汽车厂商，其通常在汽车的售后服务中进行。诊断方法400还可以包括对诊断请求数据进行处理（S402），其中，诊断请求数据可以包括针对第一核（即，需要发送到第一核/Linux）的第一诊断请求数据以及针对第二核（即，需要发送到第二核/RTOS）的第二诊断请求数据，并且处理操作可以包括例如去除报头、添加报头、转发等。诊断方法400还可以包括将处理后的诊断请求数据发送至第一核中的操作系统接口模块和/或第二核中的诊断通讯管理器模块（S403）。通常，接收和发送数据的步骤可以经由交换机来实现，交换机可以是交换机芯片的形式。

图7示出了根据本发明一实施方式的针对第二核的诊断请求数据的信号流向图。以下参考图7以及图2来具体说明本发明一实施方式的针对第二核（M核/R核）的诊断方法。如图7中所示，在图7的上半部分，诊断请求数据先从DLC 230发出，以DoIP Request报文①的形式发送到交换机240。经转发后，DoIP Request报文②被发送RTOS中的SoAd模块2203。SoAd模块2203将TCP/IP Payload⑤发送到DOIP模块2202。DOIP模块2202将去除DOIPHeader后的DOIP Payload⑦发送到PDUR模块2201，并继而到达DCM 2204。在图7的下半部分，在诊断响应过程中，数据[1]经过DCM模块2204处理而形成的数据[2]依次经过PDUR模块2201、DOIP模块2202、SoAd模块2203，并通过交换机240到达DLC 230，最终完成对第二核（M核/R核）的诊断响应。

根据本发明一实施方式的针对第一核的诊断请求数据的信号流向与图4中示出的信号流向类似。以下参考图4以及图2来具体说明本发明一实施方式的针对第一核（M核/R核）的诊断方法。如图4中所示，在图4的上半部分，诊断请求数据先从DLC 230通过DoIPRequest报文①发送到交换机。经交换机转发后，DoIP Request报文③被发送RTOS中的SoAd模块2203。SoAd模块2203将TCP/IP Payload⑤发送到DOIP模块2202。DOIP模块2202将去除DOIP Header后的DOIP Payload⑦发送到PDUR模块2201。PDUR模块2201再将此PDU⑨转发到SoAd模块2203。SoAd模块2203将添加对应PDU Header后的PDU⑪发送到交换机240。交换机240随后将此PDU⑬转发到Linux中。UDSonETH Server模块2108将去除PDU Header后的PDUPayload⑮发送到UDS Server模块2107。

图4的下半部分示出诊断响应的过程。诊断响应数据先从UDS Server模块2107通过UDS报文⑯发送到UDSonETH Server模块2108。UDSonETH Server模块2108将添加PDUHeader后的PDU⑭发送到交换机240。交换机240将该PDU⑫转发到SoAd模块2203。SoAd模块2203将去除PDU Header后的PDU Payload⑩发送到PDUR模块2201。PDUR模块2201将该PDUPayload⑧转发到DOIP模块。DOIP模块2202将添加DOIP Header后的DOIP PDU⑥发送到SoAd模块2203。SoAd模块2203将添加对应PDU Header后的PDU④发送到交换机240。交换机240将此PDU②转发到DLC 230，最终完成对第一核（A核）的诊断响应。

本发明在诊断方法中，创造性地使用了两套诊断ID来实现基于异构多核架构内核的诊断方案，该诊断方案同时适用于异构多核架构内的多种内核，降低了变更及维护成本，为其应用于高性能域控制器奠定了技术基础。

提供本文中提出的实施例和示例，以便最好地说明按照本技术及其特定应用的实施例，并且由此使本领域的技术人员能够实施和使用本发明。但是，本领域的技术人员将会知道，仅为了便于说明和举例而提供以上描述和示例。所提出的描述不是意在涵盖本发明的各个方面或者将本发明局限于所公开的精确形式。

Claims (8)

1.一种车载系统主节点的诊断刷新系统，其特征在于，包括：

第一核，在所述第一核上运行有第一操作系统，并且所述第一核包括用于产生远程刷新请求数据的远程刷新模块；

诊断记录口DLC，其用于产生DLC刷新请求数据；以及

第二核，在所述第二核上运行有第二操作系统，并且所述第二核包括用于处理所述远程刷新请求数据和/或所述DLC刷新请求数据的第二数据处理模块；

交换机，其配置成将处理后的所述DLC刷新请求数据和/或所述远程刷新请求数据发送至所述第一核中的操作系统接口模块。

2.根据权利要求1所述的诊断刷新系统，其特征在于，交换机还配置成：

通信地连接到所述第一核、所述第二核以及所述诊断记录口，并且配置成用于所述第一核、所述第二核以及所述诊断记录口之间的信号传递。

3.根据权利要求1所述的诊断刷新系统，其特征在于，所述第一核还包括：

用于处理所述远程刷新请求数据和/或所述DLC刷新请求数据和/或由所述诊断记录口DLC产生的诊断请求数据的第一数据处理模块。

4.根据权利要求1所述的诊断刷新系统，其特征在于，其中：

所述第一操作系统是Linux操作系统，以及所述第二操作系统是实时操作系统RTOS。

5.根据权利要求1所述的诊断刷新系统，其特征在于，其中：

所述第一核是Cortex-A核，以及所述第二核是Cortex-M核或Cortex-R核。

6.根据权利要求3所述的诊断刷新系统，其特征在于，其中：

所述诊断请求数据包括针对所述第一核的第一诊断请求数据以及针对所述第二核的第二诊断请求数据。

7.一种车载系统主节点的刷新方法，其特征在于，包括以下步骤：

接收来自诊断记录口的DLC刷新请求数据和/或来自第一核中的远程刷新模块的远程刷新请求数据；

对所述DLC刷新请求数据和/或所述远程刷新请求数据进行处理；以及

将处理后的所述DLC刷新请求数据和/或所述远程刷新请求数据发送至所述第一核中的操作系统接口模块。

8.根据权利要求7所述的刷新方法，其特征在于，所述接收和所述发送的步骤经由交换机来实现。

Images