一种基于ACF协议的通讯方法及相关产品

技术领域

本申请涉及车载以太网技术领域，特别是涉及一种基于ACF协议的通讯方法及相关产品。

背景技术

随着汽车技术的发展，车载网络架构正经历着从传统汽车总线向更加复杂的网络化转变。在这个过程中，新的技术如车载以太网已经开始逐步取代传统汽车总线(如控制器局域网(CAN)和媒体定义系统(MOST)等)。

然而，由于成本、兼容性和技术成熟度等原因，新旧车载总线的共存阶段将会持续相当长的一段时间。这意味着，汽车中的电子控制单元(ECU)可能需要同时处理多种传统总线的数据和车载以太网的数据。为了解决这个问题，一个常见的方法是使用服务导向消息交换(SOME/IP)协议作为车载以太网部分的替代总线。这种方式涉及到一个特殊的ECU，称为网关ECU，它同时连接到传统总线(如CAN)和车载以太网。通过软件实现将两种不同的总线数据进行转换和交换。

虽然这种方法提供了一种有效的解决方案，但SOME/IP协议同时传输控制信息和传输数据，由于控制信息和数据混合传输，数据的传输量和频率会对控制信息的实时性和可靠性产生影响，导致控制信息的传输延迟或丢失，从而影响控制系统的响应速度和稳定性。

发明内容

基于上述问题，本申请提供了一种基于ACF协议的通讯方法及相关产品，目的是通过ACF协议的方式专项传输控制信息，解决控制信息传输延迟或丢失的问题。

本申请第一方面提供了一种基于ACF协议的通讯方法，应用于汽车总线与车载以太网之间的网关ECU，所述方法包括：

接收车辆控制报文；

若所述车辆控制报文来自所述汽车总线，则基于所述车辆控制报文的格式和ACF协议的报文格式，将所述车辆控制报文转换为符合所述ACF协议的报文格式的第一转换报文，并向所述车载以太网发送所述第一转换报文；

若所述车辆控制报文来自所述车载以太网，则基于所述车辆控制报文的格式和所述汽车总线的报文格式，将所述车辆控制报文转换为符合所述汽车总线的报文格式的第二转换报文，并向所述汽车总线发送所述第二转换报文。

可选地，在所述接收车辆控制报文之前，所述方法还包括：

接收并存储来自所述车载以太网的第一关注列表；所述第一关注列表包括所述车载以太网重点关注的总线标识；

接收并存储来自所述汽车总线的第二关注列表；所述第二关注列表包括所述汽车总线重点关注的总线标识；

所述若所述车辆控制报文来自所述汽车总线，则基于所述车辆控制报文的格式和ACF协议的报文格式，将所述车辆控制报文转换为符合所述ACF协议的报文格式的第一转换报文，包括：

若所述车辆控制报文来自所述汽车总线，则根据所述第一关注列表确定所述车辆控制报文的总线标识是否位于所述第一关注列表中，若位于所述第一关注列表中，则基于所述车辆控制报文的格式和ACF协议的报文格式，将所述车辆控制报文转换为符合所述ACF协议的报文格式的第一转换报文；

所述若所述车辆控制报文来自所述车载以太网，则基于所述车辆控制报文的格式和所述汽车总线的报文格式，将所述车辆控制报文转换为符合所述汽车总线的报文格式的第二转换报文，包括：

若所述车辆控制报文来自所述车载以太网，则根据所述第二关注列表确定所述车辆控制报文的总线标识是否位于所述第二关注列表中，若位于所述第二关注列表中，则基于所述车辆控制报文的格式和所述汽车总线的报文格式，将所述车辆控制报文转换为符合所述汽车总线的报文格式的第二转换报文。

可选地，还包括：

通过SRP协议向外广播通告消息，并通过以太网网关逐级转发所述通告消息，直至到达车载以太网ECU；所述通告消息包含ACF数据流的基本信息，所述基本信息包括单包ACF报文的最大长度和发送间隔，所述最大长度和发送间隔用于计算为所述ACF数据流预留的带宽大小；

接收从所述车载以太网ECU经过以太网网关逐级回溯的对于所述通告消息的答复消息；所述答复消息用于声明所述车载以太网ECU需要接收所述ACF数据流；各级以太网网关用于记录所述基本信息和所述答复消息，并基于所述基本消息和所述答复消息设置自身的硬件参数，以为所述ACF数据流预留带宽；

所述向所述车载以太网发送所述第一转换报文，具体为：

接收到所述答复消息后，向所述车载以太网发送所述第一转换报文。

可选地，若所述车辆控制报文来自所述汽车总线，所述方法还包括：

基于车厂的ACF报文优先级设置规则，对所述第一转换报文设置优先级；或者，

确定所述汽车总线的类型，若所述汽车总线为第一类型，则为所述第一转换报文设置第一优先级，若所述汽车总线为第二类型，则为所述第一转换报文设置第二优先级；所述第一优先级高于所述第二优先级；所述第一类型的汽车总线要求传输紧急程度高于第二类型的汽车总线的控制信息。

可选地，若所述车辆控制报文来自所述汽车总线，所述汽车总线为CAN总线，所述车辆控制报文为CAN报文，则所述将所述车辆控制报文转换为符合所述ACF协议的报文格式的第一转换报文，包括：

将子类型设置为0x05，将接收到所述CAN报文的时间作为广义时钟同步协议时间，根据所述CAN报文中信息构建ACF负载；

获取所述CAN报文的数据长度，并根据所述CAN报文确定报文类型；

基于所述数据长度和所述报文类型得到ACF报文头部；

根据所述ACF负载的长度和所述ACF报文头部的长度得到流数据的长度；

根据所述子类型、所述广义时钟同步协议时间和所述流数据的长度得到AVTP的报文头部；

根据所述AVTP的报文头部、所述ACF报文头部和所述ACF负载封装得到所述第一转换报文。

本申请第二方面提供了一种基于ACF协议的通讯方法，应用于车载以太网ECU，所述方法包括：

接收来自网关ECU的第一转换报文；所述网关ECU用于在汽车总线和车载以太网之间建立通讯，所述第一转换报文为所述网关ECU在接收到来自所述汽车总线的车辆控制报文后，基于所述车辆控制报文的格式和ACF协议的报文格式，将所述车辆控制报文转换得到的ACF报文；以及，

通过所述网关ECU与所述车载以太网之间的连接，向所述网关ECU发送车辆控制报文，以使所述网关ECU根据所述车载以太网ECU发送的车辆控制报文进行格式转换，得到符合所述汽车总线的报文格式的第二转换报文，并将所述第二转换报文发送给所述汽车总线。

可选地，所述方法还包括：

在所述车载以太网ECU的内核空间实现ACF协议栈；

在所述车载以太网ECU的用户空间内的应用程序调用所述内核空间的ACF协议栈注册自身信息，注册时需提供重点关注的总线标识，在注册流程中基于密钥文件与所述ACF协议栈进行安全认证；

根据总线标识的不同，在所述内核空间创建与总线标识一一对应的设备文件，并根据应用程序的注册信息为各应用程序分配针对所述设备文件的访问权限。

可选地，所述接收来自网关ECU的第一转换报文，包括：

所述ACF协议栈在接收到所述第一转换报文后，根据所述第一转换报文中的总线标识将所述第一转换报文写入缓冲区；

目标应用程序接收缓冲区可读取的通知，所述目标应用程序为注册时提供了所述第一转换报文中的总线标识的应用程序；

所述目标应用程序在接收到所述缓冲区可读取的通知后，通过所述第一转换报文中的总线标识对应的设备文件读取所述第一转换报文。

可选地，所述向所述网关ECU发送车辆控制报文，包括：

所述车载以太网ECU的用户空间中应用程序向设备文件写入车辆控制信息，以控制所述ACF协议栈根据所述车辆控制信息封装得到车辆控制报文；

所述ACF协议栈发送所述车辆控制报文。

本申请第三方面提供了一种网关ECU，所述网关ECU位于汽车总线与车载以太网之间；所述网关ECU包括：

接收模块，用于接收车辆控制报文；

转换模块，用于若所述车辆控制报文来自所述汽车总线，则基于所述车辆控制报文的格式和ACF协议的报文格式，将所述车辆控制报文转换为符合所述ACF协议的报文格式的第一转换报文，和/或，用于若所述车辆控制报文来自所述车载以太网，则基于所述车辆控制报文的格式和所述汽车总线的报文格式，将所述车辆控制报文转换为符合所述汽车总线的报文格式的第二转换报文；

发送模块，用于向所述车载以太网发送所述第一转换报文，和/或，用于向所述汽车总线发送所述第二转换报文。

本申请第四方面提供了一种车载以太网ECU，包括：

接收模块，用于接收来自网关ECU的第一转换报文；所述网关ECU用于在汽车总线和车载以太网之间建立通讯，所述第一转换报文为所述网关ECU在接收到来自所述汽车总线的车辆控制报文后，基于所述车辆控制报文的格式和ACF协议的报文格式，将所述车辆控制报文转换得到的ACF报文；

发送模块，用于通过所述网关ECU与所述车载以太网之间的连接，向所述网关ECU发送车辆控制报文，以使所述网关ECU根据所述车载以太网ECU发送的车辆控制报文进行格式转换，得到符合所述汽车总线的报文格式的第二转换报文，并将所述第二转换报文发送给所述汽车总线。

本申请第五方面一种基于ACF协议的通讯系统，包括：汽车总线、车载以太网以及上述第三方面所提供网关ECU。

相较于现有技术，本申请具有以下有益效果：

在本方案中，提供了一种基于ACF协议的通讯方法，应用于汽车总线与车载以太网之间的网关ECU。网关ECU可以接收来自汽车总线和车载以太网两种类型的车辆控制报文；当车辆控制报文来自汽车总线，网关基于车辆控制报文的格式和ACF协议的报文格式，将车辆控制报文转换为符合ACF协议的报文格式的第一转换报文，并向车载以太网发送第一转换报文；若车辆控制报文来自车载以太网，则基于车辆控制报文的格式和汽车总线的报文格式，将车辆控制报文转换为符合汽车总线的报文格式的第二转换报文，并向汽车总线发送第二转换报文。由于在本方案中，网关能够基于ACF协议实现不同总线类型的车辆控制报文转换，使网关通过ACF协议的方式专项传输控制信息，因此避免了传输数据的传输量和频率对控制信息产生影响。可见本方案解决了控制信息传输延迟或丢失的问题。

附图说明

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

图1为本申请实施例提供的一种基于ACF协议通讯的架构示意图；

图2为本申请实施例提供的一种基于ACF协议的通讯方法的流程图；

图3为本申请实施例提供的一种实现第一转换报文的方法流程图；

图4为本申请实施例提供的一种ACF负载的示意图；

图5为本申请实施例提供的一种ACF报文头部的示意图；

图6为本申请实施例提供的一种AVTP的报文头部的示意图；

图7为本申请实施例提供的一种基于关注列表的ACF协议的通讯方法的方法流程图；

图8为本申请实施例提供的一种基于SPR协议实现流预留的方法流程图；

图9为本申请实施例提供的一种车载以太网ECU的结构示意图；

图10为本申请实施例提供的一种基于ACF协议的通讯方法的流程图；

图11为本申请实施例提供的一种车载以太网ECU接收来自网关ECU的第一转换报文的结构示意图；

图12本申请实施例提供的一种接收来自网关ECU的第一转换报文的方法流程图；

图13为本申请实施例提供的一种车载以太网ECU向外发送车辆控制报文的结构示意图；

图14为本申请实施例提供的一种向网关ECU发送车辆控制报文的方法流程图；

图15为本申请实施例提供的一种网关ECU的示意图；

图16为本申请实施例提供的一种车载以太网ECU的示意图；

图17为本申请实施提供的基于ACF协议的通讯系统示意图。

具体实施方式

正如前文描述，目前由于成本、兼容性和技术成熟度等原因，新旧车载总线的共存阶段将会持续相当长的一段时间。相关技术使用服务导向消息交换(SOME/IP)协议作为车载以太网部分的替代总线。利用网关ECU同时连接到传统总线(如CAN)和车载以太网，通过软件实现将两种不同的总线数据进行转换和交换。一方面，SOME/IP协议在进行数据传输时会同时传输控制信息和传输数据，但是传统总线中很大一部分数据都是对实时性要求较高的控制信息，当控制信息和传输数据信息混杂在一起时，数据的传输量和频率会对控制信息的实时性和可靠性产生影响。并且若新旧车载总线数据在中转时产生了延迟，很难通过SOME/IP自身的机制进行回溯。同时SOME/IP协议缺乏有效的服务质量(QualityofService，QoS)机制来确保在网络带宽不足时的时效性。QoS是网络的一种安全机制，是用来解决网络延迟和阻塞等问题的一种技术。另一方面，SOME/IP的运行时基于动态订阅的，恶意程序可以轻易的伪装成正常程序来进行服务的订阅，从而向传统总线发送攻击报文影响安全性。

发明人经过研究，提出通过网关ECU基于ACF协议实现不同总线类型的车辆控制报文转换，实现专项传输车辆的控制信息，可以避免传输数据对控制信息产生影响。

有鉴于此，本申请实施提供了一种基于ACF协议的通讯方法，应用于汽车总线与车载以太网之间的网关ECU。网关ECU可以接收来自传统汽车总线和车载以太网两种类型的车辆控制报文；当车辆控制报文来自传统汽车总线，网关基于车辆控制报文的格式和ACF协议的报文格式，将车辆控制报文转换为符合ACF协议的报文格式的第一转换报文，并向车载以太网发送第一转换报文；若车辆控制报文来自车载以太网，则基于车辆控制报文的格式和汽车总线的报文格式，将车辆控制报文转换为符合汽车总线的报文格式的第二转换报文，并向汽车总线发送第二转换报文。由于在本方案中，网关能够基于ACF协议实现不同总线类型的车辆控制报文转换，使网关通过ACF协议的方式专项传输控制信息，因此避免了传输数据的传输量和频率对控制信息产生影响。可见本方案解决了控制信息传输延迟或丢失的问题。

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

下面首先结合附图具体说明本方案基于ACF协议通讯的架构。

图1为本申请实施例提供的一种基于ACF协议通讯的架构示意图。结合图1所示，基于ACF协议通讯的架构示意图包括CAN网络11、网关ECU 21和车载以太网31。

需要说明的是，传统汽车总线可以为LIN总线、FlexRay总线、MOST总线等。在本实施例的架构示意图中，以CAN总线作为示例进行说明，在实际的应用过程中，图1所示的CAN网络11还可以替换为LIN网络等传统车载总线对应的网络。

在CAN网络11中可以包括多个ECU，例如ECU-1至ECU-n。ECU-1至ECU-n可以表示车载系统的发动机控制单元(ECU)、制动系统控制单元(ECU)、底盘控制单元(ECU)、仪表盘控制单元(ECU)等。其中每个ECU中均包括一个CAN模块，CAN模块允许ECU通过CAN总线与其他ECU进行双向的实时通信。通过CAN总线，ECU可以发送和接收消息，以实现数据共享和协同控制。每个ECU中的CAN模块负责处理与CAN总线相关的任务，包括消息的发送和接收、消息的解析和封装、通信速率的控制等等。整个车载系统中的多个ECU通过CAN总线连接在一起，形成一个分布式的车辆电子系统。

车载以太网31中也可以包括多个车载以太网ECU，例如ECU-1至ECU-m。其中每个ECU中各自和一个以太网网关(Eth Switch，又称以太网交换机)连接，对应以太网网关-1至以太网网关-m。具体地，ECU和以太网网关存在两种可能的连接方式，一种是将以太网网关集成在ECU中，另一种是在ECU内部集成以太网媒体接入控制器(MAC)和物理接口收发器(PHY)，通过将以太网MAC/PHY集成到ECU中，ECU可以与外部的以太网网关连接，以实现车辆内部的网络通信。这极大地简化了车内系统的互联和数据交换，同时提供了更高的带宽和速度。需要说明的是，外部的以太网网关可以是一个独立的部件，也可以集成在其他ECU中。

以太网网关允许车载以太网ECU通过以太网与其他ECU进行双向的实时通信。通过车载以太网，车载以太网ECU可以发送和接收消息，以实现数据共享和协同控制。在车载以太网31中，每个ECU中的以太网网关负责处理与以太网相关的任务，包括消息的发送和接收、消息的解析和封装、通信速率的控制等等。整个车载系统中的多个ECU通过以太网连接在一起，形成一个分布式的车辆电子系统。车载以太网31还可以包括用于转发各ECU中以太网网关发送的报文的以太网网关S。可以理解的是，图中仅以一个以太网网关S作为示例，在实际的应用过程，车载以太网31中可能存在多个以太网网关S用于转发各ECU中以太网网关发送的各种报文。

网关ECU 21是位于CAN网络与车载以太网之间的网关ECU。用于对来自于CAN网络和来自于车载以太网的控制报文进行传输和转换。具体的，网关ECU包括CAN模块210、以太网网关211和互译软件213。其中，CAN模块210用于从CAN网络11中接收各ECU中CAN模块发送的CAN报文，以太网网关211用于从车载以太网31中接收各ECU中通过以太网网关发送的ACF报文。需要说明的是，以太网网关211从车载以太网31中接收各ECU中通过以太网网关发送的ACF报文存在多种可能的实现方式。例如，以太网网关211通过车载以太网31中的各ECU中的以太网网关接收ACF报文，以太网网关211还可以接收通过车载以太网31中的由以太网网关S转发的各ECU中的以太网网关发送的ACF报文。可以理解的是，图中仅以一个以太网网关S作为示例，在实际的应用过程，车载以太网31中可能存在多个以太网网关用于转发ECU中以太网网关发送的各种报文。

图2为本申请实施例提供的一种基于ACF协议的通讯方法的流程图。应用于汽车总线与车载以太网之间的网关ECU。结合图2所示，所述基于ACF协议的通讯方法可以包括：

步骤S201：接收车辆控制报文。

在本步骤中，车辆控制报文可以来自于汽车总线和以太网总线。其中，汽车总线也叫汽车传统总线，是车辆内部网络的基础架构的旧总线，可以包括CAN总线(ControllerArea Network)、LIN总线(Local Interconnect Network)和FlexRay总线以及MOST总线(Media Oriented Systems Transport)等。

具体地，CAN总线用于车辆的各个子系统和设备之间的通信，如发动机管理系统、车身电子系统、底盘控制系统等。可以传输各种类型的数据，如传感器数据、控制命令、故障诊断信息等。LIN总线是一种低速、低成本的串行总线，主要用于连接车辆中的辅助设备，如门锁、窗户控制器、座椅控制器等。FlexRay总线是一种高速、实时性能强的串行总线，主要用于车辆中需要高带宽和高可靠性的通信需求。例如用于传输复杂的车辆控制数据，如刹车系统、转向系统等。MOST总线是一种用于多媒体和娱乐系统的高带宽串行总线。例如用于音频、视频和数据的传输，支持多媒体设备的连接和控制，如音响系统、导航系统等。

以太网总线作为车辆内部网络的基础架构，是车辆内部网络中的一种新总线，用于连接各种电子控制单元(ECU)，如发动机控制单元、传感器、执行器、娱乐系统等。具体地，以太网总线可以用于传输车辆控制命令和数据，如电动车辆的电池管理系统、动力分配系统、智能驾驶辅助系统等。通过汽车总线和车载以太网之间的转换实现不同新旧总线的通信，从而实现对车辆的控制。

具体地，汽车总线和车载以太网之间的转换通过汽车总线和车载以太网之间网关ECU实现。网关ECU实现可以包括多种总线的接收模块，用于根据多种总线对应的通信协议接收来自不同总线的车辆控制报文。以CAN总线为例，网关ECU可以包括CAN模块和以太网网关。其中，CAN模块用于接收由CAN总线发送的控制报文，以太网网关用于接收由车载以太网发送的控制报文。对于不同来源的车辆控制报文的处置，下面通过步骤S202和S203分别加以介绍。需要说明的是，S202与S203是基于不同的报文来源采取的独立的处理措施，图2中仅提供了一种流程顺序的示例，结合具体情况，两个步骤的执行顺序还可以是同步执行，或者先执行S203再执行S202。

步骤S202：若车辆控制报文来自汽车总线，则基于车辆控制报文的格式和ACF协议的报文格式，将车辆控制报文转换为符合ACF协议的报文格式的第一转换报文，并向车载以太网发送第一转换报文。

在本步骤中，当车辆控制报文来自汽车总线时，网关ECU通过互译软件根据车辆控制报文的格式，解析出相关的数据并进行格式转换，以便将车辆控制报文转换为符合ACF协议的报文格式的第一转换报文。例如，当车辆控制报文为CAN报文时，网关ECU根据CAN报文的格式和定义，解析CAN报文，提取出相关的数据和控制信息。具体包括CAN报文包括报文ID、数据长度、数据域以及校验等。进一步的，网关ECU的互译软件根据对照CAN报文和ACF报文的格式，将CAN报文中的数据映射到ACF报文对应的字段中，以确保将CAN报文中的数据正确地映射到ACF报文中相应的位置。然后，根据ACF协议的报文格式要求，将CAN报文中的数据按照ACF协议的格式进行数据类型转换、字节顺序调整等操作，以确保ACF报文的格式与ACF协议要求的格式一致。

在一个可选的实施例中，可以根据AVTP的封装规则对数据进行封装。对于实现ACF功能来说，AVTP的报文分成了三部分，包括AVTP报文头部、ACF报文头部、负载。图3为本申请实施例提供的一种实现第一转换报文的方法流程图。若车辆控制报文来自汽车总线，汽车总线为CAN总线，车辆控制报文为CAN报文，则如图3所示，将车辆控制报文转换为符合所述ACF协议的报文格式的第一转换报文可以包括以下步骤S301-S306：

S301：将子类型设置为0x05，将接收到CAN报文的时间作为广义时钟同步协议时间，根据CAN报文中信息构建ACF负载。

在本步骤中，网关ECU解析接收到的CAN报文，从CAN报文中相关信息构建ACF负载。当AVTP的控制格式为时间敏感的控制格式，此时AVTP报头部分的Subtype固定为0x05，而AVTP报头部分的Avtp_timestamp为接收到这一包CAN数据时的gPTP时间。

图4为本申请实施例提供的一种ACF负载的示意图。结合图4所示，其中，ACF负载的“mtv”用来标记后续的“message_timestamp”是否被使用。由于在前面的“AVTP报文头部”中已经提供过“avtp_timestamp”了。因此，这里的“message_timestamp”可以根据需求选用。也可以通过设置“mtv”为0来禁用。具体地，在AVTP报文头部中已经提供了“avtp_timestamp”，因此使用“message_timestamp”是可选的，并且可以根据具体需求进行选择。如果需要使用“message_timestamp”，可以将“mtv”设置为1来启用；如果不需要使用，则可以将“mtv”设置为0来禁用。这种设计允许根据具体应用的需求决定是否需要使用额外的时间戳信息。在某些情况下，AVTP报文头部的“avtp_timestamp”可能已足够满足时间戳需求，而不需要使用额外的“message_timestamp”。通过设置“mtv”为0，可以禁用“message_timestamp”，从而减少不必要的信息传输和处理。

ACF负载的“rtr”字段与CAN报文头部的“rtr(remote transmission request,远程发送请求位)”相同。ACF负载的“eff”字段用于表示是否启用“扩展格式”。若CAN报文启用扩展格式，则用ACF负载的“fdf”字段表示CAN报文的具体格式，0表示这包数据是CAN报文，1表示这包数据是CAN FD报文。ACF负载的“brs”即CAN报文的比特率切换位“bit rateswitch”。ACF负载的“esi”字段是CAN消息的错误状态标识位。ACF负载的“can_bus_id”字段对应的CAN总线的ID。若对CAN总线的ID不关注或获取不到，则用0进行填充。ACF负载的“can_identifier”字段表示这包CAN报文的ID。ACF负载的“can_msg_payload”字段表示这包CAN报文的报文内容。ACF负载的“pad”和“rsv”字段是用来补齐占位的无意义内容，可以忽略。

通过将从CAN报文或者CAN FD报文中获取的相关信息以及AVTP报头部分的Avtp_timestamp的设置，将相关数据分别填入相应的位置构建得到ACF负载。

S302：获取CAN报文的数据长度，并根据CAN报文确定报文类型。

在本步骤中，通过解析CAN报文的数据长度字段获取CAN报文的数据长度。具体地，CAN报文的数据长度字段通常位于CAN帧的第一个字节的低四位中。通过提取该字段，可以获取CAN报文的数据长度信息，根据CAN报文的数据长度字段的值，可以计算出CAN报文的实际数据长度。数据长度字段的取值范围是0到8，表示数据字段中包含的数据字节数。例如，数据长度字段的值为3，CAN报文的数据长度为3个字节。

根据CAN报文的标识符(ID)来确定报文类型。具体地，根据CAN标识符的不同位(如标准帧的ID标识符位或扩展帧的ID标识符位)来进行报文类型的判断和分类。

S303：基于数据长度和报文类型得到ACF报文头部。

图5为本申请实施例提供的一种ACF报文头部的示意图。结合图5所示，ACF报文头部包括“acf_msg_type”和“acf_msg_length”。其中，“acf_msg_type”字段用于表示报文类型，“acf_msg_length”字段用于表示数据长度。

当转发的是CAN报文时，“acf_msg_type”固定为0x01。则“acf_msg_length”具体表示CAN报文的数据长度。

通过上述操作，将数据长度和报文类型写入到对应的ACF报文字段得到ACF报文头部。

S304：根据ACF负载的长度和ACF报文头部的长度得到流数据的长度。

在本步骤中，通过上述步骤S301-S303，得到了ACF负载和ACF报文头部，进一步获取ACF负载的长度和ACF报文头部的长度，计算得到流数据的长度。具体地，将ACF负载的长度和ACF报文头部的长度相加，即可得到流数据的长度。这个长度表示ACF报文中承载的实际媒体数据的长度。例如，ACF负载的长度为10字节，ACF报文头部的长度为6字节。那么，流数据的长度可以通过以下计算得到：流数据的长度＝ACF负载的长度+ACF报文头部的长度＝10字节+6字节＝16字节，即流数据的长度为16字节。这个长度表示ACF报文中实际承载的媒体数据的长度。需要说明的是，上述示例仅用于说明计算的方法，实际的ACF协议和应用可能具有不同的字段定义和长度单位。因此，在实际应用中，根据相关的ACF协议规范和文档来准确计算流数据的长度。

S305：根据子类型、广义时钟同步协议时间和流数据的长度得到AVTP的报文头部。

前文提到，当AVTP的控制格式为时间敏感的控制格式，此时AVTP报头部分的Subtype固定为0x05，而AVTP报头部分的Avtp_timestamp为接收到这一包CAN数据时的广义时钟同步协议时间(gPTP时间)。图6为本申请实施例提供的一种AVTP的报文头部的示意图。结合图6所示，其中，AVTP报头部分的Subtype(子类型)字段固定为0x05，即时间敏感的AVTP控制格式；AVTP报头部分的StreamID根据用户的需求进行设置，用于标识特定的流；AVTP报头部分的Avtp_timestamp字段为接收到这一包CAN数据时的gPTP时间。AVTP报头部分的Stream_data_length字段为“ACF报文头部”的长度加上“ACF负载”的长度。需要说明的是，AVTP报头部分还包括其他定义字段，例如，CD字段，即通道标识，表示数据流的通道编号。若要将数据流发送到通道1，那么CD字段的值为1。Sv字段，即服务字段，用于标识不同的服务类型。若发送的数据流属于视频流服务类型，那么Sv字段的值为1。Mr字段，即消息类型字段，用于标识不同的消息类型。若发送的消息属于控制消息类型，那么Mr字段的值为1。需要说明的是，上述只是示例性的给出了其他定义字段，在实际的应用过程中，还可以包括更多的定义字段。

S306：根据AVTP的报文头部、ACF报文头部和ACF负载封装得到第一转换报文。

在上文中提到，AVTP的报文分成了三部分，包括AVTP报文头部、ACF报文头部、负载。通过步骤S301-S305，分别获得了AVTP的报文头部、ACF报文头部和ACF负载，根据AVTP的封装规则对将AVTP的报文头部、ACF报文头部和ACF负载进行封装，得到第一转换报文。

在一个可选的实施例中，由于汽车总线对应的CAN ID具有不同的优先级，为了确保控制指令被更快的发送、接收和处理，可以对ACF报文设置不同的优先级。故，所述方法还包括：基于车厂的ACF报文优先级设置规则，对第一转换报文设置优先级；或者，确定汽车总线的类型，若汽车总线为第一类型，则为第一转换报文设置第一优先级，若汽车总线为第二类型，则为第一转换报文设置第二优先级；第一优先级高于第二优先级；第一类型的汽车总线要求传输紧急程度高于第二类型的汽车总线的控制信息。

在本实施例中，由于推荐AVTP数据帧使用2和3这两个默认的优先级，因此车厂可以在此基础上对于不同CAN ID设置优先级，然后基于车厂的ACF报文优先级设置规则，网关ECU对优先级较高的第一转换报文优先进行封装和发送。

若车厂没有指定，则按着高速CAN和低速CAN区分优先级。也就是若汽车总线为高速CAN，为所述第一转换报文设置第一优先级，即高速CAN上传输的数据的优先级为3。若汽车总线为低速CAN，为第一转换报文设置第二优先级，低速CAN上传输的数据的优先级为2。网关ECU对第一优先级的第一转换报文优先进行封装和发送。

步骤S203：若车辆控制报文来自车载以太网，则基于车辆控制报文的格式和汽车总线的报文格式，将车辆控制报文转换为符合汽车总线的报文格式的第二转换报文，并向汽车总线发送第二转换报文。

在本步骤中，当车辆控制报文来自车载以太网时，网关ECU通过互译软件根据车辆控制报文的格式，解析出相关的数据并进行格式转换，以便将车辆控制报文转换为符合汽车总线的报文格式的第二转换报文。例如，当车辆控制报文为车载以太网报文时，网关ECU根据车载以太网报文的格式和定义，解析车载以太网报文，提取出报文头部、ACF报文头部和ACF负载。进一步的，网关ECU的互译软件根据对照CAN报文和ACF报文的格式，将车载以太网报文中的数据映射到CAN报文对应的字段中，以确保将ACF报文中的数据正确地映射到CAN报文中相应的位置。然后，根据CAN协议的报文格式要求，将ACF报文中的数据按照CAN协议的格式进行数据类型转换、字节顺序调整等操作，以确保ACF报文的格式与CAN协议要求的格式一致。网关ECU在完成第二转换报文之后并向汽车总线发送第二转换报文。

在上述实施例中，网关能够基于ACF协议实现不同总线类型的车辆控制报文转换，使网关通过ACF协议的方式专项传输控制信息，因此避免了传输数据的传输量和频率对控制信息产生影响。可见本方案解决了控制信息传输延迟或丢失的问题。

在本申请实施例中，上述图2所述的步骤S202之前存在多种可能的实现方式，下面分别进行介绍。需要说明的是，下文介绍中给出的实现方式仅作为示例性的说明，并不代表本申请实施例的全部实现方式。

根据上文所述，网关ECU需要进行转换和传输多个来自于车载以太网和汽车总线的车辆控制数据。图7为本申请实施例提供的一种基于关注列表的ACF协议的通讯方法的方法流程图。结合图7所示，所述步骤S202之前还可以包括：

S801：接收并存储来自车载以太网的第一关注列表。

在本步骤中，第一关注列表包括车载以太网重点关注的总线标识。网关ECU通过接收和存储来自于车载以太网的第一关注列表，以便在后续接收汽车总线的车辆控制报文转换第一转换报文时只关注车载以太网需要的车辆控制报文。

具体地，网关ECU通过车载以太网接口，接收到又车载以太网发送的包含第一关注列表的数据，对接收到的数据进行解析，提取出车载以太网所需的第一关注列表信息。例如，从接收到的数据中获取总线标识，关注的总线标识为CAN1和CAN2，根据总线标识来执行特定的操作或判断是否对特定的车辆控制报文进行转换，将提取出的总线标识存储在数据库、配置文件或内存数据结构中，以便后续使用。

当网关ECU存储有车载以太网的第一关注列表，上述步骤S202若车辆控制报文来自汽车总线，则基于车辆控制报文的格式和ACF协议的报文格式，将车辆控制报文转换为符合ACF协议的报文格式的第一转换报文，可以包括：若车辆控制报文来自汽车总线，则根据第一关注列表确定车辆控制报文的总线标识是否位于第一关注列表中，若位于第一关注列表中，则基于车辆控制报文的格式和ACF协议的报文格式，将车辆控制报文转换为符合ACF协议的报文格式的第一转换报文。

具体而言，网关ECU从车辆控制报文中获取总线标识。总线标识可能是特定的ID或其他标识符，用于唯一标识报文所属的总线。在获取总线标识后，检查报文的总线标识是否在第一关注列表中，如果车辆控制报文的总线标识在第一关注列表中，则基于车辆控制报文的格式和ACF协议的报文格式，将车辆控制报文转换为符合ACF协议的报文格式的第一转换报文。具体的报文转换过程参见步骤S202，在此不做赘述。

S802：接收并存储来自所述汽车总线的第二关注列表。

在本步骤中，第二关注列表包括汽车总线重点关注的总线标识。网关ECU通过接收和存储来自于汽车总线的第二关注列表，以便在后续接收车载以太网的车辆控制报文转换第二转换报文时只关注汽车总线需要的车辆控制报文。

具体地，网关ECU通过汽车总线接口，接收到由汽车总线发送的包含第二关注列表的数据，对接收到的数据进行解析，提取出汽车总线所需的第二关注列表信息。例如，从接收到的数据中获取总线标识，关注的总线标识为A和B，根据总线标识来执行特定的操作或判断是否对特定的车辆控制报文进行转换，将提取出的总线标识存储在数据库、配置文件或内存数据结构中，以便后续使用。

当网关ECU存储有汽车总线的第二关注列表，上述步骤S203若车辆控制报文来自车载以太网，则基于车辆控制报文的格式和汽车总线的报文格式，将车辆控制报文转换为符合汽车总线的报文格式的第二转换报文，包括：若车辆控制报文来自车载以太网，则根据第二关注列表确定车辆控制报文的总线标识是否位于第二关注列表中，若位于第二关注列表中，则基于车辆控制报文的格式和汽车总线的报文格式，将车辆控制报文转换为符合汽车总线的报文格式的第二转换报文。

具体而言，网关ECU从车辆控制报文中获取总线标识。总线标识可能是特定的ID或其他标识符，用于唯一标识报文所属的总线。在获取总线标识后，检查报文的总线标识是否在第二关注列表中，如果车辆控制报文的总线标识在第二关注列表中，则基于车辆控制报文的格式和ACF协议的报文格式，将车辆控制报文转换为符合ACF协议的报文格式的第二转换报文。具体的报文转换过程参见步骤S203，在此不做赘述。

在本申请实施例中，上述图2所述的步骤S202之前存在多种可能的实现方式，下面分别进行介绍。需要说明的是，下文介绍中给出的实现方式仅作为示例性的说明，并不代表本申请实施例的全部实现方式。

根据前文所述，根据整车设计，网关ECU和车载以太网部分拓扑中可能存在一到多个以太网网关，即Eth Switch，为了确保在各个以太网网关中都给ACF报文预留了足够的带宽。即使正在使用车载以太网满负荷的传输用户级数据，也能保证在需要时，立刻让出足够的带宽来传输ACF报文。图8为本申请实施例提供的一种基于SPR协议实现流预留的方法流程图。结合图8所示，所述步骤S202之前还可以包括：

S901：通过SRP协议向外广播通告消息，并通过以太网网关逐级转发通告消息，直至到达车载以太网ECU。

SRP(Stream Reservation Protocol)协议是一种用于实时流媒体传输的协议，它提供了流预留机制，以确保实时流的可靠传输和时限要求。具体可以通过发送方向网络中的调度器发送请求，申请预留网络资源来传输特定的流。调度器接收到流请求后，根据网络资源的可用性和预留策略，分配适当的网络资源用于传输该流。分配的资源可能包括带宽、缓存空间、传输优先级等。调度器将分配的网络资源与发送方的数据流进行绑定，确保发送方的数据流在网络中按照预留的资源条件进行传输。在流绑定后，发送方开始将实时数据流发送到网络中，而调度器和网络中的其他节点(如交换机、路由器)根据预留的资源条件进行数据传输。

在本步骤中，网关ECU构建一个通告消息，使用SRP协议向外广播该通告消息，在以太网中，使用以太网网关将通告消息逐级转发，直至到达车载以太网ECU。以太网网关负责将消息从一个以太网子网转发到另一个以太网子网，以确保消息能够到达目标节点，在每个节点接收到通告消息后，解析其中的基本信息，为ACF数据流预留的带宽大小。其中，通告消息包含ACF数据流的基本信息，基本信息包括单包ACF报文的最大长度和发送间隔，最大长度和发送间隔用于计算为ACF数据流预留的带宽大小。若发送间隔为不定期，则给出可能的最小间隔。需要说明的是，该通告消息还可以包括ACF数据流的Stream ID、使用的VLAN等基本信息。

S902：接收从车载以太网ECU经过以太网网关逐级回溯的对于通告消息的答复消息。

在本步骤中，答复消息用于声明车载以太网ECU需要接收ACF数据流。各级以太网网关用于记录基本信息和答复消息，并基于基本消息和答复消息设置自身的硬件参数，以为ACF数据流预留带宽。

具体而言，当车载以太网ECU对网关ECU发送的通告消息进行答复，就是声明自己需要接收这个ACF数据流。该答复通过以太网网关逐级回溯到网关ECU。沿途的所有以太网网关需要记录这个信息，并设置自身的硬件参数，以实现为对应的ACF数据流预留足够的带宽。例如，接收到的基本信息为单包ACF报文的最大长度为100字节，发送间隔为10毫秒。答复消息表示车载以太网ECU需要接收ACF数据流。在答复消息回溯过程中，沿途的所有以太网网关根据最大长度，确定每个ACF报文的数据量为100字节，根据发送间隔，将1000毫秒(1秒)除以发送间隔10毫秒，得到每秒传输的ACF报文数量为100个。将每秒传输的ACF报文数量乘以每个ACF报文的数据量(100个*100字节)，得到每秒需要的带宽为10,000字节/秒得到每秒需要的带宽。

需要说明的是，在实际的应用过程中，需要考虑额外的开销，如帧头、校验和等。根据具体情况，确定额外开销的大小，并将其加入到带宽计算中，并根据网络的可用带宽、拥塞状况和其他因素，进行调整和限制，以确保为ACF数据流预留的带宽大小在可承受的范围内。

在一个可选的实施例中，利用SRP协议来进行动态的流预留订阅管理。也就是说，通过流预留的带宽并非空置，在没有ACF数据流流通的情况下，预留出的带宽可以用于其他用途。但是，当需要时，以太网网关对其他数据进行限流，使得正在通讯的数据流立刻降速，以便并让出对应的带宽给ACF数据流。

具体而言，以太网网关通过监测ACF数据流的流通情况，判断是否有ACF数据流正在传输，当没有ACF数据流流通时，可以将预留的带宽用于其他用途，例如传输其他数据流，当有ACF数据流需要传输时，需要立即降速其他正在通信的数据流，以便为ACF数据流腾出对应的带宽。

S903：接收到答复消息后，向车载以太网发送第一转换报文。

在上述实施例中，通过利用SRP协议来进行动态的流预留订阅管理，并使用静态配置的方式固定配置网络中的各个网关的流预留配置。确保ACF数据流在需要时能够立即传输，从而提供实时性和及时性。同时，预留带宽的机制允许在没有ACF数据流流通时将其用于其他用途，提高带宽的利用率。

在本申请实施例中，上述实施例提供了一种应用于汽车总线与车载以太网之间的网关ECU的基于ACF协议的通讯方法，本申请实施例还提供了一种应用于车载以太网ECU的基于ACF协议的通讯方法。需要说明的是，下文介绍中给出的实现方式仅作为示例性的说明，并不代表本申请实施例的全部实现方式。

图9为本申请实施例提供的一种车载以太网ECU的结构示意图。结合图9所示，所述车载以太网ECU包括内核空间110和用户空间111。

其中，用户空间111包括N个应用程序，通过向设备文件写入信息来控制ACF协议栈发送ACF报文。在此之前，目标应用程序会根据自身的需求，调用内核中的ACF协议栈1010来注册自身信息。注册时需要提供自身关注的CAN ID等关键信息以便获得对应设备文件的访问权限。当目标应用程序在接收到对应设备文件可读取的通知后，通过第一转换报文中的总线标识在对应的设备文件中读取第一转换报文。

内核空间110用于根据总线标识的不同创建一个或多个设备文件。具体可以包括ACF协议栈1010和N个设备文件。ACF协议栈1010用于处理ACF报文，并根据目标应用程序的注册信息注册应用程序的信息并进行安全认证，当应用程序安全认证通过时，ACF协议栈1010为目标应用程序分配设备文件的访问权限。N个设备文件用来统一处理与N个设备文件中CAN ID对应的报文。

图10为本申请实施例提供的一种基于ACF协议的通讯方法的流程图。应用于车载以太网ECU。结合图10所示，所述基于ACF协议的通讯方法可以包括：

S1101：接收来自网关ECU的第一转换报文。

在本步骤中，网关ECU用于在汽车总线和车载以太网之间建立通讯，第一转换报文为网关ECU在接收到来自汽车总线的车辆控制报文后，基于车辆控制报文的格式和ACF协议的报文格式，将车辆控制报文转换得到的ACF报文。

在一个可选的实施例中，为了使得车载以太网ECU接收来自网关ECU的第一转换报文，需要在车载以太网ECU实现对应的框架设置和权限管理，以保证数据的安全性。故，所述方法还包括：在车载以太网ECU的内核空间实现ACF协议栈；在车载以太网ECU的用户空间内的应用程序调用内核空间的ACF协议栈注册自身信息，注册时需提供重点关注的总线标识，在注册流程中基于密钥文件与ACF协议栈进行安全认证；根据总线标识的不同，在内核空间创建与总线标识一一对应的设备文件，并根据应用程序的注册信息为各应用程序分配针对设备文件的访问权限。

具体而言，车载以太网ECU包括用户空间和内核空间。用户空间中运行有多个应用程序，多个应用程序可以通过访问内核空间的文件获取对应的数据。在车载以太网ECU的内核空间中可以实现一个ACF协议栈用来处理ACF报文。同时，根据总线标识的不同，内核会创建一到多个设备文件。

当用户空间内的应用程序需要访问内核空间中的设备文件时，在车载以太网ECU的用户空间内的应用程序会调用内核空间的ACF协议栈注册自身信息，注册时需提供重点关注的总线标识，每个应用程序可注册关注一个或多个总线标识即可以访问一个到多个设备文件。根据应用程序的注册信息为各应用程序分配针对设备文件的访问权限。

进一步为了保证应用程序的安全性，ACF协议栈和应用程序之间可以定义基于密钥文件的认证机制。当用户空间内的应用程序调用内核空间的ACF协议栈注册自身信息时，ACF协议栈会基于密钥文件对目标应用程序进行安全认证，当目标应用程序通过安全认证之后，ACF协议栈根据应用程序的注册信息为各应用程序分配针对设备文件的访问权限。通过上述操作，避免恶意应用程序接入内核空间获取总线数据，降低安全风险。

在一个可选的实施例中，鉴于CAN消息报文长度的限制，一个总线标识对应的消息报文可能无法涵盖一个功能的所有消息指令。因此常见的CAN消息矩阵中，通常都会由一个到多个总线标识对应的CAN消息组合到一起来完成一个完整的功能。例如，ATS功能可能涉及到ATS_1、ATS_2、ATS_3这三组CAN消息，总线标识分别是0x101、0x102、0x103。将三个CANID放到一起才能完成完整的ATS功能。因此，会利用一个设备文件用来统一处理这三条总线标识对应的报文。在本实施中，通过设备文件以功能集为单位进行组织，避免创建太多的设备文件浪费系统资源。

图11为本申请实施例提供的一种车载以太网ECU接收来自网关ECU的第一转换报文的结构示意图。结合图11所示，该结构车载以太网1210、网关ECU1211和CAN网络1212。其中，在车载以太网1210可以包括用户空间和内核空间，用户空间中包括应用程序m和设备文件m，内核空间包括ACF协议栈。

当车载以太网ECU1210接收来自网关ECU的第一转换报文时，应用程序m接收设备文件m的可读取的通知，并在接收到设备文件m可读取的通知后，通过第一转换报文中的总线标识对应的设备文件m读取第一转换报文。设备文件m用于和ACF协议栈进行空间交换，存储由ACF协议栈写入的第一转换报文。内核空间中的ACF协议栈用于接收到第一转换报文，并接收到第一转换报文后，将接收到的第一转换报文写入设备文件m中。

网关ECU 1211包括以太网网关、互译软件和CAN模块，网关ECU 1211中的CAN模块用于接收由CAN网络1212中ECU-m通过CAN网络1212中ECU-m的CAN模块发送的车辆控制报文。互译软件用于将CAN网络1212发送车辆控制报文转换成ACF报文，并通过以太网网关与车载以太网1210中内核空间的ACF协议栈通信，将ACF报文发送到车载以太网1210中。

根据上述车载以太网ECU实现对应的框架设置和权限管理，图12本申请实施例提供的一种接收来自网关ECU的第一转换报文的方法流程图。结合图12所示，上述接收来自网关ECU的第一转换报文可以包括：

S1201：ACF协议栈在接收到第一转换报文后，根据第一转换报文中的总线标识将第一转换报文写入缓冲区。

在本步骤中，由于内核空间根据总线标识创建了一到多个设备文件，ACF协议栈在接收到第一转换报文后，对第一转换报文进行解析，得到第一转换报文中总线标识。根据总线标识，确定需要将第一转换报文写入的相应缓冲区，然后将接收到的第一转换报文写入总线标识对应的缓冲区中。

S1202：目标应用程序接收缓冲区可读取的通知。

目标应用程序为注册时提供了第一转换报文中的总线标识的应用程序。

在本步骤中，当缓冲区写入新的报文时，ACF协议栈通过定时器、轮询或其他方式各个缓冲区的状态，检测是否有新的报文写入。当某个缓冲区中有新的报文可读取时，ACF协议栈向目标应用程序发送通知。

S1203：目标应用程序在接收到缓冲区可读取的通知后，通过第一转换报文中的总线标识对应的设备文件读取第一转换报文。

在本步骤中，目标应用程序接收到ACF协议栈的通知，该通知表示某个缓冲区中有新的报文可读取，目标应用程序从通知中获取到与之关联的总线标识。这个总线标识可以用于识别特定的设备文件。目标应用程序根据总线标识打开相应的设备文件，通过读取已打开的设备文件，目标应用程序从缓冲区中读取第一转换报文，在处理完报文后，目标应用程序还可以通过关闭已打开的设备文件，以释放资源。

以上S1101介绍的是车载以太网ECU接收车辆控制报文的情形。相应地，车载以太网也可能向外发送车辆控制报文，相应地，通过S1102进行介绍。需要说明的是，本申请实施例中S1101和S1102可以是相互独立进行的，因此，对于S1101和S1102的执行顺序不加以限定。

S1102：通过网关ECU与车载以太网之间的连接，向网关ECU发送车辆控制报文，以使网关ECU根据车载以太网ECU发送的车辆控制报文进行格式转换，得到符合汽车总线的报文格式的第二转换报文，并将第二转换报文发送给汽车总线。

图13为本申请实施例提供的一种车载以太网ECU向外发送车辆控制报文的结构示意图。结合图13所示，该结构车载以太网1310、网关ECU1311和CAN网络1313.其中，在车载以太网1310可以包括用户空间和内核空间，用户空间中包括应用程序n和设备文件n，内核空间包括ACF协议栈。

当车载以太网ECU1310向CAN网络1313发送车辆控制报文时，应用程序n用于打开与ACF协议栈通信的设备文件，将车辆控制信息写入设备文件n中。设备文件n用于和ACF协议栈进行空间交换，将车辆控制信息传递给ACF协议栈。ACF协议栈用于根据协议规范和通信要求，将车辆控制信息封装成车辆控制报文并发送到网关ECU 1311。

网关ECU 1311包括以太网网关、互译软件和CAN模块，网关ECU 1211中的以太网网关用于接收由车载以太网ECU 1310中ACF协议栈发送的车辆控制报文。互译软件用于将车载以太网ECU 1310通过ACF协议栈发送车辆控制报文转换成CAN报文，并通过CAN模块与CAN网络1313中ECU-n的CAN模块通信，将CAN报文发送到CAN网络1313中的ECU-n中。

在一个可选的实施例中，图14为本申请实施例提供的一种向网关ECU发送车辆控制报文的方法流程图。结合图14所示，所述向网关ECU发送车辆控制报文可以包括：

S1301：车载以太网ECU的用户空间中应用程序向设备文件写入车辆控制信息，以控制ACF协议栈根据车辆控制信息封装得到车辆控制报文。

具体而言，在应用程序中，首先打开与ACF协议栈通信的设备文件。应用程序通过写入设备文件的方式，将车辆控制信息传递给ACF协议栈。车辆控制信息可能包括控制命令、参数设置等。ACF协议栈接收到车辆控制信息后，根据协议规范和通信要求，将车辆控制信息封装成车辆控制报文。

S1302：ACF协议栈发送车辆控制报文。

ACF协议栈将封装好的车辆控制报文发送到车载以太网上。

通过上述实施例，车载以太网ECU通过ACF协议栈和应用程序之间安全认证机制和基于权限访问等机制。防止恶意程序向汽车总线中发送攻击报文，降低安全风险。

图15为本申请实施例提供的一种网关ECU的示意图，该网关ECU位于汽车总线与车载以太网之间。所述网关ECU1400包括：

接收模块1401，用于接收车辆控制报文；

转换模块1402，用于若所述车辆控制报文来自所述汽车总线，则基于所述车辆控制报文的格式和ACF协议的报文格式，将所述车辆控制报文转换为符合所述ACF协议的报文格式的第一转换报文，和/或，用于若所述车辆控制报文来自所述车载以太网，则基于所述车辆控制报文的格式和所述汽车总线的报文格式，将所述车辆控制报文转换为符合所述汽车总线的报文格式的第二转换报文；

发送模块1403，用于向所述车载以太网发送所述第一转换报文，和/或，用于向所述汽车总线发送所述第二转换报文。

在所述接收车辆控制报文之前，所述网关ECU还包括：

第一关注列表获取模块，用于接收并存储来自所述车载以太网的第一关注列表；所述第一关注列表包括所述车载以太网重点关注的总线标识；

第二关注列表获取模块，用于接收并存储来自所述汽车总线的第二关注列表；所述第二关注列表包括所述汽车总线重点关注的总线标识；

所述转换模块1402，具体用于：

若所述车辆控制报文来自所述汽车总线，则根据所述第一关注列表确定所述车辆控制报文的总线标识是否位于所述第一关注列表中，若位于所述第一关注列表中，则基于所述车辆控制报文的格式和ACF协议的报文格式，将所述车辆控制报文转换为符合所述ACF协议的报文格式的第一转换报文；

所述转换模块1402，具体用于：

若所述车辆控制报文来自所述车载以太网，则根据所述第二关注列表确定所述车辆控制报文的总线标识是否位于所述第二关注列表中，若位于所述第二关注列表中，则基于所述车辆控制报文的格式和所述汽车总线的报文格式，将所述车辆控制报文转换为符合所述汽车总线的报文格式的第二转换报文。

所述网关ECU还包括：

通告消息广播模块，用于通过SRP协议向外广播通告消息，并通过以太网网关逐级转发所述通告消息，直至到达车载以太网ECU；所述通告消息包含ACF数据流的基本信息，所述基本信息包括单包ACF报文的最大长度和发送间隔，所述最大长度和发送间隔用于计算为所述ACF数据流预留的带宽大小；

答复消息接收模块，用于接收从所述车载以太网ECU经过以太网网关逐级回溯的对于所述通告消息的答复消息；所述答复消息用于声明所述车载以太网ECU需要接收所述ACF数据流；各级以太网网关用于记录所述基本信息和所述答复消息，并基于所述基本消息和所述答复消息设置自身的硬件参数，以为所述ACF数据流预留带宽；

所述发送模块1403，具体用于：

接收到所述答复消息后，向所述车载以太网发送所述第一转换报文。

若所述车辆控制报文来自所述汽车总线，所述网关ECU还包括优先级设置模块，用于：

基于车厂的ACF报文优先级设置规则，对所述第一转换报文设置优先级；或者，

确定所述汽车总线的类型，若所述汽车总线为第一类型，则为所述第一转换报文设置第一优先级，若所述汽车总线为第二类型，则为所述第一转换报文设置第二优先级；所述第一优先级高于所述第二优先级；所述第一类型的汽车总线要求传输紧急程度高于第二类型的汽车总线的控制信息。

图16为本申请实施例提供的一种车载以太网ECU的示意图。车载以太网ECU 1500包括：

接收模块1501，用于接收来自网关ECU的第一转换报文；所述网关ECU用于在汽车总线和车载以太网之间建立通讯，所述第一转换报文为所述网关ECU在接收到来自所述汽车总线的车辆控制报文后，基于所述车辆控制报文的格式和ACF协议的报文格式，将所述车辆控制报文转换得到的ACF报文；

发送模块1502，用于通过所述网关ECU与所述车载以太网之间的连接，向所述网关ECU发送车辆控制报文，以使所述网关ECU根据所述车载以太网ECU发送的车辆控制报文进行格式转换，得到符合所述汽车总线的报文格式的第二转换报文，并将所述第二转换报文发送给所述汽车总线。

所述车载以太网ECU，还包括：

ACF协议栈实现模块，用于在所述车载以太网ECU的内核空间实现ACF协议栈；

注册信息模块，用于在所述车载以太网ECU的用户空间内的应用程序调用所述内核空间的ACF协议栈注册自身信息，注册时需提供重点关注的总线标识，在注册流程中基于密钥文件与所述ACF协议栈进行安全认证；

设备文件模块，用于根据总线标识的不同，在内核空间创建与总线标识一一对应的设备文件，并根据应用程序的注册信息为各应用程序分配针对设备文件的访问权限。

所述接收模块1501，具体用于：

所述ACF协议栈在接收到所述第一转换报文后，根据所述第一转换报文中的总线标识将所述第一转换报文写入缓冲区；

目标应用程序接收缓冲区可读取的通知，所述目标应用程序为注册时提供了所述第一转换报文中的总线标识的应用程序；

所述目标应用程序在接收到所述缓冲区可读取的通知后，通过所述第一转换报文中的总线标识对应的设备文件读取所述第一转换报文。

所述发送模块1502，具体用于：

所述车载以太网ECU的用户空间中应用程序向设备文件写入车辆控制信息，以控制所述ACF协议栈根据所述车辆控制信息封装得到车辆控制报文；

所述ACF协议栈发送所述车辆控制报文。

图17为本申请实施提供的基于ACF协议的通讯系统示意图。结合图17所示，该系统1600包括汽车总线1601、车载以太网1602以及网关ECU 1603。

关于网关ECU 620的说明可以参见上述网关ECU实施例，本实施例在此不再赘述。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备及系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的设备及系统实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元提示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅为本申请的一种具体实施方式，但本申请保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此本申请保护范围应该以权利要求的保护范围为准。