CN117061518A - 一种云原生虚拟can通信系统及方法 - Google Patents

Abstract

本申请公开了一种云原生虚拟CAN通信系统及方法，属于虚拟CAN通信技术领域，云原生虚拟CAN通信系统运行在容器化的云服务环境中；云原生虚拟CAN通信系统包括：虚拟CAN总线模组，独立运行在一个容器组中，用于通过路由方式传输消息数据；虚拟ECU服务模组，与虚拟CAN总线模组通信连接，包括若干虚拟ECU节点，每个虚拟ECU节点均独立运行在一个容器组中，且各虚拟ECU节点均通过虚拟CAN总线模组收发消息数据。本申请提供的云原生虚拟CAN通信系统及方法利用云原生技术，能够支撑虚拟ECU之间通信需求，实现了多场景开发测试任务，很好的实现整车的数字孪生。

Description

一种云原生虚拟CAN通信系统及方法

技术领域

本申请涉及一种云原生虚拟CAN通信系统及方法，属于虚拟CAN通信技术领域。

背景技术

Electronic Control Unit电子控制单元简称ECU，是汽车中控制某个具体功能的模块。常见的ECU比如： TCU（Transmision Control Unit）自动变速箱控制单元、VGM（Vehicle Gateway Module）车辆网关模块、BMS（Battery Management System）电池管理系统等。Controller Area Network控制器局域网简称CAN，是一种基于异步串行传输方式的总线通信技术，它可以使用双绞线来传输信号，主要用于车辆中的各个ECU之间进行通信。CAN总线将汽车上的各种电子装置与设备连成一个网络，实现相互之间的信息共享，既减少了线束，又可更好地控制和协调汽车的各个系统，使汽车性能达到最佳。汽车CAN总线分低速CAN（波特率10~125Kbps）和高速CAN（波特率125~1000Kbps），网络有多种结构，如网状连接，串型连接，环型连接，星型连接，总线连接等。

传统整车ECU研发，严重依赖硬件，成本高昂且稀缺，异地协同资源调度难，试验车测试成本高，导致开发测试效率较低。在软件定义汽车发展趋势下，为了彻底软硬解耦，摆脱对硬件的依赖，规避硬件资源及损坏等造成开发测试停滞的问题，诞生了虚拟ECU技术来实现虚拟孪生汽车云。虚拟ECU是真实ECU的数字孪生，用软件模拟微处理器、存储器、总线等，包含必要的组件和功能，可以在Windows桌面电脑或云平台上以容器化的方式作为独立的服务运行，而无需依赖目标硬件，提高研发效率。多个虚拟ECU交互的情况就需要虚拟CAN总线来支撑虚拟ECU之间通信需求。

虚拟CAN通信技术，作为虚拟孪生汽车云的技术底座，在汽车ECU软件研发（OTA升级、自动驾驶、ECU参数标定，故障注入测试等）领域，起到了关键支撑作用。目前，通过在计算机系统中模拟CAN总线网络来实现CAN通信的方法，是使用CAN总线协议栈软件来实现的，例如：CANalyzer、CAN Explorer，都是CAN网络通信和调试工具。但它们都是国外商用软件，并且仅支持Windows桌面电脑运行的，不支持容器云环境。所以就需要基于云原生容器技术，实现虚拟CAN通信方法，来支撑虚拟孪生汽车云。

发明内容

本申请的目的在于提供一种云原生虚拟CAN通信系统及方法，利用云原生技术，能够支撑虚拟ECU之间通信需求，实现了多场景开发测试任务，很好的实现整车的数字孪生。

为实现上述目的，本申请第一方面提供了一种云原生虚拟CAN通信系统，所述云原生虚拟CAN通信系统运行在容器化的云服务环境中；

所述云原生虚拟CAN通信系统包括：

虚拟CAN总线模组，独立运行在一个容器组中，用于通过路由方式传输消息数据；

虚拟ECU服务模组，与所述虚拟CAN总线模组通信连接，包括若干虚拟ECU节点，每个虚拟ECU节点均独立运行在一个容器组中，且各虚拟ECU节点均通过所述虚拟CAN总线模组收发消息数据；

其中，每个虚拟ECU节点均包括运行在同一个容器组中的虚拟CAN适配器和CAN驱动接口，所述虚拟CAN适配器通信连接于CAN驱动接口与所述虚拟CAN总线模组之间，用于对所述CAN驱动接口与所述虚拟CAN总线模组之间的消息数据进行解析和传输。

在一种实施方式中，所述虚拟ECU服务模组还包括：若干用于提供虚拟ECU服务的应用程序；每个所述应用程序与一个虚拟ECU节点通信连接，并通过所述虚拟ECU节点中的CAN驱动接口调用收发的消息数据。

在一种实施方式中，所述虚拟CAN适配器包括：连接模块，与所述虚拟CAN总线模组通信连接，用于在所述应用程序与所述虚拟CAN总线模组之间建立连接；

虚拟CAN收发器，通信连接于所述连接模块和所述CAN驱动接口之间，用于对所述CAN驱动接口和所述连接模块之间的消息数据进行解析和传输。

在一种实施方式中，所述CAN驱动接口收发的消息数据的结构为CAN帧数据；所述虚拟CAN收发器包括：CAN收发适配器接口，与所述CAN驱动接口通信连接，用于对CAN帧数据进行传输。

在一种实施方式中，所述连接模块包括多个信道，每个信道代表一个会话任务；所述虚拟CAN收发器还包括：若干数据发送器和若干数据接收器，每个信道与一个数据发送器或数据接收器通信连接；

所述数据发送器将所述CAN收发适配器接口接收的CAN帧数据进行序列化后通过相应信道发送到所述虚拟CAN总线模组；

所述数据接收器将相应信道中的数据反序列化形成CAN帧数据并发送至所述CAN收发适配器接口。

在一种实施方式中，所述虚拟CAN总线模组包括交换机和若干消息队列；所述交换机用于接收各个虚拟CAN适配器发送的消息数据，并将消息数据路由到指定的消息队列；

所述消息队列用于存储收到的消息数据并通过推送技术机制将消息数据推送至相应的虚拟CAN适配器。

在一种实施方式中，所述交换机根据不同的路由规则与相应的消息队列绑定，并根据各路由规则将消息数据路由到指定的消息队列，其中，各路由规则分别用于标识不同的CAN类型。

本申请第二方面提供了一种云原生虚拟CAN通信方法，包括：各应用程序通过如上述第一方面或上述第二方面任一项实施方式所述的云原生虚拟CAN通信系统进行信息交互。

本申请第三方面提供了一种电子设备，包括：存储器、处理器以及存储在存储器中并可在处理器上运行的计算机程序，该处理器执行计算机程序时实现上述第二方面中的步骤。

本申请第四方面提供了一种计算机可读存储介质，上述计算机可读存储介质存储有计算机程序，上述计算机程序被处理器执行时实现上述第一方面或者上述第二方面中的步骤。

由上可见，本申请提供了一种云原生虚拟CAN通信系统及方法，本申请提供的系统整体部署在私有云环境，可应用于支撑虚拟孪生汽车云平台的服务。在虚拟孪生汽车云平台中，虚拟ECU作为基础技术，支撑虚拟车的运行。依赖云服务资源弹性伸缩，可以支撑ECU软件研发中高并发测试验证，这是硬件在环测试和实车测试所不具备的先天优势。虚拟CAN在ECU中CAN驱动接口层级，能够完全模拟汽车高速CAN（波特率最大为1Mbps）的功能特性，实时性强、可靠性高、有优先权和仲裁功能、可根据报文的ID决定接收或屏蔽该报文、具有可靠的错误处理和检错机制、报文可仅使用标志符广播信息、避免信道堵塞等。实际使用中经测试验证，每秒钟传输数据量能够达到250KB以上，相当于模拟了波特率为1Mbps的汽车高速CAN总线传输能力，能够支撑虚拟ECU之间通信需求，实现了多场景开发测试任务，很好的实现整车的数字孪生。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种虚拟CAN通信结构示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其他实施例中也可以实现本申请。在其它情况下，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在本申请说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本申请。如在本申请说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。

下面结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请的一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在下面的描述中阐述了很多具体细节以便于充分理解本申请，但是本申请还可以采用其它不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施例的限制。

实施例一

云原生技术支撑研发快速迭代，自动部署，服务独立高效，拥有可伸缩性，高可靠性，安全与强壮性等优势，越来越得到认可，已经在汽车软件研发中得到应用。本申请实施例提供了一种云原生虚拟CAN通信系统，如图1所示，该云原生虚拟CAN通信系统运行在容器化的云服务环境中；

所述云原生虚拟CAN通信系统包括：

虚拟CAN总线模组（Virtual CAN Bus），独立运行在一个容器组（k8s pod）中，用于通过路由方式传输消息数据；

虚拟ECU服务模组，与所述虚拟CAN总线模组通信连接，包括若干虚拟ECU节点，每个虚拟ECU节点均独立运行在一个容器组中，且各虚拟ECU节点均通过所述虚拟CAN总线模组收发消息数据；

其中，每个虚拟ECU节点均包括运行在同一个容器组中的虚拟CAN适配器（VirtualCAN Adapter）和CAN驱动接口，所述虚拟CAN适配器通信连接于CAN驱动接口与所述虚拟CAN总线模组之间，用于对所述CAN驱动接口与所述虚拟CAN总线模组之间的消息数据进行解析和传输。

在一种实施方式中，云原生虚拟CAN通信系统（简称虚拟CAN）作为基础组件服务，以微服务的形式，部署运行在容器化的云服务环境中，即k8s管理的私有云上。它包含两部分内容。虚拟CAN总线模组是独立的总线服务，独立运行在一个容器组中，各虚拟ECU节点要想通过总线传输消息，就需要连接到总线。具体的，Virtual CAN Bus提供消息传输路由服务，维护从发送节点到接收节点的传输线路，保证消息数据能按照指定的路径传输，来支持业务实现，是虚拟CAN通信的重要组成部分。虚拟CAN适配器是作为连接总线和虚拟ECU服务模组中CAN驱动接口的适配器，在总线和CAN驱动接口之间起到承上启下的作用，部署在虚拟ECU容器组中的一个容器（k8s container）中，是实现虚拟CAN通信的重要组成部分，起到解析和传输的作用。

可选的，所述虚拟ECU服务模组还包括：若干用于提供虚拟ECU服务的应用程序；每个所述应用程序与一个虚拟ECU节点通信连接，并通过所述虚拟ECU节点中的CAN驱动接口调用收发的消息数据。

在一种实施方式中，各应用程序（App）分别基于如车辆网关模块（VGM）、车身控制模块（BCM）、自动变速箱控制单元（TCU）、电池管理系统（BMS）等各功能模块提供不同的虚拟ECU服务，每个虚拟ECU节点与一种应用程序对应并提供相应的虚拟ECU服务，本申请实施例中，图1所示的虚拟CAN通信结构以提供VGM和BCM虚拟ECU服务的虚拟ECU节点为例来说明设计，各虚拟ECU节点单独运行在一个K8s环境中的容器化虚拟ECU容器组（Virtual ECU k8spod）中，且均与Virtual CAN Bus通信连接。

在一种实施方式中，App不属于“虚拟CAN”的范畴，它使用CAN驱动的标准接口（即CAN驱动接口）调用收发数据。App是可以运行在真实ECU的C/C++应用程序，当然也可以作为独立的模块运行在虚拟ECU的环境，在图1中展示了真实ECU应用无缝接入“虚拟CAN”的使用方式，在任一虚拟ECU节点中，App与相应的Virtual CAN Adapter部署在同一个虚拟ECU容器组中。

可选的，所述虚拟CAN适配器包括：连接模块（Connection），与所述虚拟CAN总线模组通信连接，用于在所述应用程序与所述虚拟CAN总线模组之间建立连接；

虚拟CAN收发器（Virtual CAN Transceiver），通信连接于所述连接模块和所述CAN驱动接口之间，用于对所述CAN驱动接口和所述连接模块之间的消息数据进行解析和传输，其中，对消息数据进行解析即序列化和反序列化CAN帧数据。

在一种实施方式中，在虚拟ECU通信网络中的每一个虚拟ECU服务都需要和Virtual CAN Bus服务建立连接（三次握手），这个连接就是一条TCP提供的可靠投递长连接（TCP Connection），会执行认证、IP解析、路由等底层网络任务。当一个虚拟ECU不再需要连接到Virtual CAN Bus的时候，需要优雅的释放掉这个连接（四次挥手），而不是直接将TCP连接关闭。

可选的，所述CAN驱动接口收发的消息数据的结构为CAN帧数据；

所述虚拟CAN收发器包括：

CAN收发适配器接口（Adapter Client），与所述CAN驱动接口通信连接，用于对CAN帧数据进行传输。虚拟ECU节点的应用运行环境提供CAN驱动接口收发CAN帧数据，对应的CAN收发适配器接口对接CAN驱动接口，作为客户端连接应用节点，转发CAN帧数据。

在一种实施方式中，ECU应用驱动程序即APP收发的数据结构为基础CAN数据帧结构（can_frame），实际应用中参考Socket CAN的源码，结合了虚拟CAN的实际情况，帧结构如下：

struct can_frame {

canid_tcan_id;

__u8can_dlc;

__u8can_type;

__u8__res0;

__u8__res1;

__u8data[CAN_MAX_DLEN];

};

其中，canid_t，是无符号32位整数类型；__u8，是无符号字符类型。

can_id，CAN标识符结构，实际使用中采用标准帧结构如下：

bit 0-28：CAN标识符（11/29 bit），标准帧就使用低11位，扩展帧就使用29位；

bit 29：错误消息帧标志，0表示数据帧，1表示错误消息，用于错误检查；

bit 30：远程传输请求标志， 0表示数据帧，1表示为遥控帧；

bit 31：帧格式标志，0表示标准帧11位，1表示扩展帧29位。

can_dlc，帧数据负载长度（0~8），以字节为单位。

can_type，CAN类型，示例：0 1 2 …（can0 can1 can2 …）。

__res0，__res1，保留数据位，保证数据结构4字节对齐。

data，帧数据负载数组，根据ISO 11898-1，数组长度CAN_MAX_DLEN为8。

可选的，所述连接模块包括多个信道（Channel，也称消息通道），是建立在Connection连接之上的一种轻量级的连接。每个Connection里可以建立多个信道，每个信道代表一个会话任务，被指派一个唯一的ID。为避免过多的消耗TCP连接资源，虚拟CAN总线模组的设计实现采用类似NIO（Non-blocking I/O）的做法，选择TCP连接复用，不仅可以减少性能开销，同时也便于管理。

所述虚拟CAN收发器还包括：若干数据发送器（Sender）和若干数据接收器（Receiver），每个信道与一个数据发送器或数据接收器通信连接；

所述数据发送器将所述CAN收发适配器接口接收的CAN帧数据进行序列化后通过相应信道发送到所述虚拟CAN总线模组；

所述数据接收器将相应信道中的数据反序列化形成CAN帧数据并发送至所述CAN收发适配器接口。

可选的，所述虚拟CAN总线模组包括交换机（Exchange）和若干消息队列（Queue）；

Virtual CAN Bus接收到消息数据时，所述交换机用于接收各个虚拟CAN适配器发送的消息数据，并将消息数据路由（Routing）到指定的消息队列并派发；

所述消息队列即存储消息数据的队列，每条消息数据都会被投送到一个或多个消息队列中，所述消息队列通过推送（PUSH）技术机制将存储的消息数据推送至相应的虚拟CAN适配器的Channel，等待Receiver来处理消息。

可选的，所述交换机根据不同的路由规则（can0/can1…）与相应的消息队列绑定（Binding），并根据各路由规则将消息数据路由到指定的消息队列，其中，各路由规则分别用于标识不同的CAN类型。

在一种实施方式中，Binding作用就是将Exchange和Queue按照路由规则绑定起来，是后续Exchange确定消息路由的依据（或关键字）。Exchange根据路由规则进行消息数据投递，投递到之前Binding依据（关键字）对应的那个消息队列。路由规则用于标识CAN类型，例如动力CAN、舒适CAN等。整车系统中存在多条CAN总线，它们分布在不同的域中，或者在同一个域中起着不同的传输作用。

在一种实施方式中，从App发出的CAN帧数据，Adapter Client收到后，Sender对CAN帧数据进行序列化并通过Channel发送到Exchange上，通过Exchange和Queue进行消息数据分发。为实现资源有效利用，Sender在发送消息数据时，通过can_frame结构中的can_type字段标识的CAN类型决定消息数据投递路由规则（can0/can1…）。各Receiver对应每一路Channel启动监听的独立线程，通过Channel，监听相应队列中是否存在消息数据，接收并反序列化形成CAN帧数据，解析can_type字段标识的CAN类型，通过Adapter Client发送给相应App，实现各虚拟ECU服务之间的通信交互。

由上可见，本申请实施例提供了一种云原生虚拟CAN通信系统，系统整体部署在私有云环境，可应用于支撑虚拟孪生汽车云平台的服务。在虚拟孪生汽车云平台中，虚拟ECU作为基础技术，支撑虚拟车的运行。依赖云服务资源弹性伸缩，可以支撑ECU软件研发中高并发测试验证，这是硬件在环测试和实车测试所不具备的先天优势。虚拟CAN在ECU中CAN驱动接口层级，能够完全模拟汽车高速CAN（波特率最大为1Mbps）的功能特性，实时性强、可靠性高、有优先权和仲裁功能、可根据报文的ID决定接收或屏蔽该报文、具有可靠的错误处理和检错机制、报文可仅使用标志符广播信息、避免信道堵塞等。实际使用中经测试验证，每秒钟传输数据量能够达到250KB以上，相当于模拟了波特率为1Mbps的汽车高速CAN总线传输能力，能够支撑虚拟ECU之间通信需求，实现了多场景开发测试任务，很好的实现整车的数字孪生。

实施例二

本申请实施例提供了一种云原生虚拟CAN通信方法，包括：各应用程序通过如上述实施例一中任一项实施方式所述的云原生虚拟CAN通信系统进行信息交互。

在一种实施方式中，云原生虚拟CAN通信系统整体部署在私有云环境，以虚拟整车OTA测试验证场景为例进行说明：OTA车端程序运行在虚拟网关（VGM）中，程序需要从虚拟CAN总线模组上读取车辆状态（如车速限制，挡位状态，蓄电池电量，发动机状态，驻车状态，动力电池电量，充电状态等），来判断升级策略，决定是否执行升级。车辆状态是其他虚拟ECU节点（BCM ，ECM等）发送到虚拟CAN总线模组上的状态信号。另外，对其他虚拟ECU节点的刷写升级如果是DOCAN（Diagnostic communication over Controller Area Network）方式，那么OTA车端程序需要将下载的升级包数据分包通过虚拟CAN发送，待升级虚拟ECU接收数据，校验，执行刷写等。这一切都运行在容器化的云服务环境中，充分应用了云原生技术。资源弹性伸缩，可以支撑功能验证及高并发测试验证。在云服务资源充足的情况下，同时运行10000台以上虚拟车来测试OTA，成为了必不可少的测试用例，但这在现有的台架式的硬件在环测试中是不可能实现的。

在其他实施方式中，其他如自动驾驶场景，ECU参数标定场景，故障注入测试场景等，虚拟CAN都能有效的模拟ECU中CAN数据的收发传递，并能够达到性能要求，很好的支撑了虚拟孪生汽车云平台的服务。

由上可见，本申请实施例提供了一种云原生虚拟CAN通信方法，能够支撑虚拟ECU之间通信需求，实现了多场景开发测试任务，很好的实现整车的数字孪生。

实施例三

本申请实施例提供了一种电子设备，该电子设备包括存储器、处理器以及存储在上述存储器中并可在上述处理器上运行的计算机程序，其中，存储器用于存储软件程序以及模块，处理器通过运行存储在存储器的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器和处理器通过总线连接。具体地，处理器通过运行存储在存储器的上述计算机程序时实现上述实施例二中的任一步骤。

应当理解，在本申请实施例中，所称处理器可以是中央处理单元(CentralProcessing Unit，CPU)，该处理器还可以是其他通用处理器、数字信号处理器 (DigitalSignal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器可以包括只读存储器、快闪存储器和随机存储器，并向处理器提供指令和数据。存储器的一部分或全部还可以包括非易失性随机存取存储器。

应当理解，上述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，上述计算机程序可存储于以计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，上述计算机程序包括计算机程序代码，上述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。上述计算机可读介质可以包括：能够携带上述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、电载波信号、电信信号以及软件分发介质等。需要说明的是，上述计算机可读存储介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将上述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

需要说明的是，上述实施例所提供的方法及其细节举例可结合至实施例提供的装置和设备中，相互参照，不再赘述。

在本申请所提供的实施例中，应该理解到，所揭露的装置/终端设备和方法，可以通过其他的方式实现。例如，以上所描述的装置/设备实施例仅仅是示意性的，例如，上述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以由另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。

上述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (10)

1.一种云原生虚拟CAN通信系统，其特征在于，所述云原生虚拟CAN通信系统运行在容器化的云服务环境中；

所述云原生虚拟CAN通信系统包括：

虚拟CAN总线模组，独立运行在一个容器组中，用于通过路由方式传输消息数据；

虚拟ECU服务模组，与所述虚拟CAN总线模组通信连接，包括若干虚拟ECU节点，每个虚拟ECU节点均独立运行在一个容器组中，且各虚拟ECU节点均通过所述虚拟CAN总线模组收发消息数据；

其中，每个虚拟ECU节点均包括运行在同一个容器组中的虚拟CAN适配器和CAN驱动接口，所述虚拟CAN适配器通信连接于CAN驱动接口与所述虚拟CAN总线模组之间，用于对所述CAN驱动接口与所述虚拟CAN总线模组之间的消息数据进行解析和传输。

2.如权利要求1所述的云原生虚拟CAN通信系统，其特征在于，所述虚拟ECU服务模组还包括：若干用于提供虚拟ECU服务的应用程序；

每个所述应用程序与一个虚拟ECU节点通信连接，并通过所述虚拟ECU节点中的CAN驱动接口调用收发的消息数据。

3.如权利要求2所述的云原生虚拟CAN通信系统，其特征在于，所述虚拟CAN适配器包括：

连接模块，与所述虚拟CAN总线模组通信连接，用于在所述应用程序与所述虚拟CAN总线模组之间建立连接；

虚拟CAN收发器，通信连接于所述连接模块和所述CAN驱动接口之间，用于对所述CAN驱动接口和所述连接模块之间的消息数据进行解析和传输。

4.如权利要求3所述的云原生虚拟CAN通信系统，其特征在于，所述CAN驱动接口收发的消息数据的结构为CAN帧数据；

所述虚拟CAN收发器包括：CAN收发适配器接口，与所述CAN驱动接口通信连接，用于对CAN帧数据进行传输。

5.如权利要求4所述的云原生虚拟CAN通信系统，其特征在于，所述连接模块包括多个信道，每个信道代表一个会话任务；

所述虚拟CAN收发器还包括：若干数据发送器和若干数据接收器，每个信道与一个数据发送器或数据接收器通信连接；

所述数据发送器将所述CAN收发适配器接口接收的CAN帧数据进行序列化后通过相应信道发送到所述虚拟CAN总线模组；

所述数据接收器将相应信道中的数据反序列化形成CAN帧数据并发送至所述CAN收发适配器接口。

6.如权利要求1所述的云原生虚拟CAN通信系统，其特征在于，所述虚拟CAN总线模组包括交换机和若干消息队列；

所述交换机用于接收各个虚拟CAN适配器发送的消息数据，并将消息数据路由到指定的消息队列；

所述消息队列用于存储收到的消息数据并通过推送技术机制将消息数据推送至相应的虚拟CAN适配器。

7.如权利要求6所述的云原生虚拟CAN通信系统，其特征在于，所述交换机根据不同的路由规则与相应的消息队列绑定，并根据各路由规则将消息数据路由到指定的消息队列，其中，各路由规则分别用于标识不同的CAN类型。

8.一种云原生虚拟CAN通信方法，其特征在于，包括：各应用程序通过如权利要求1-7任一项所述的云原生虚拟CAN通信系统进行信息交互。

9.一种电子设备，包括：存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求8所述方法的步骤。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求8所述方法的步骤。