CN115543661B - 数据分发装置及分发方法、车辆电子操作系统的架构 - Google Patents

Abstract

本申请涉及一种数据分发装置，包括框架服务模块，用于调用下述各模块以实现数据的分发；API接口模块，用于获得发布者OS或订阅者OS的主题信息；链路协议适配模块，用于对传输映射模块解封装获得的各帧数据组装形成车辆数据，车辆数据中记载有主题信息，以及基于主题信息匹配出车辆数据的订阅者OS；传输映射模块，用于对接收自发布者OS的报文依据该发布者OS的底层传输协议进行解封装获得各帧数据，或将各帧数据依据匹配出的订阅者OS的底层传输协议进行封装发送。还相应提供了数据分发方法。本发明可以满足各OS之间数据分发及交互需求，实现了各OS之间数据收发的低耦合性或非耦合性，简化了各OS的集成难度。

Description

数据分发装置及分发方法、车辆电子操作系统的架构

技术领域

本申请涉及计算机操作系统领域，尤其涉及一种数据分发装置、车辆电子操作系统的架构、数据分发方法及计算设备。

背景技术

在车辆电子操作系统技术领域，随着车辆电动化、网联化、智能化的快速发展，给车辆带来了诸多新技术变革。车辆的业务功能越来越复杂，尤其是近年来智能座舱、智能驾驶、智能底盘的需求推动下促使了车辆电子电气架构的技术变革。各大车企在EEA(车辆电子电气架构，EEA,Electrical/Electronic Architecture)架构整车集中化、芯片原厂推出的高计算能力芯片、多核异构处理器集群化、主机厂的整车软件整合能力逐步提升，中央式整车智能座舱合一平台化的需求推动下，座舱域不断集成新的功能，智能座舱正从单域向跨域融合方向演进，如座舱域与ADAS(高级驾驶辅助系统，advanced driver assistancesystem)域融合，甚至部分主机厂已开始着手车云一体化多域中央计算平台的研发布局。在这种趋势下车辆电子操作系统厂商也紧随芯片原厂适配出符合主机厂新业务需求的高端车辆电子虚拟化操作系统架构。如当前在智能座舱领域主流的基于微内核架构的虚拟化操作系统，以期设计的架构符合整车智能化需求的操作系统解决方案。

但是，随着电动化、智能化、网联化的快速发展，车辆电子功能ECU(ElectronicControl Unit，电子控制单元)逐渐增加，在基于微内核架构实时系统环境下运行的虚拟化异构OS也在不断增加，目前使用的基于微内核架构的虚拟化异构OS之间通过共享内存及虚拟IO进行信息互通，实时和非实时业务耦合在一起，也逐步严重的增加了系统的复杂性和降低了系统的可靠性，以及增加了虚拟化异构OS之间同步开发和集成的难度，虚拟化操作系统的资源划分对技术要求较高以及系统操作与配置存在较大的复杂度，从而使得微内核架构的虚拟化异构OS在车辆电子领域的广泛应用受到了很多的限制。

由于基于微内核架构的虚拟化异构OS功能越来越强大，实时系统和非实时系统融合在一起，存在的不足也越来越显现，功能强大必然增加了系统的复杂性和降低了系统的可靠性，进而导致异构OS之间同步开发和最终版本的集成和联调带来了的难度，从而使得微内核架构的虚拟化异构OS在车辆电子领域的广泛应用受到了诸多限制。

发明内容

鉴于现有技术的以上问题，本申请提供一种数据分发装置及分发方法、车辆电子操作系统的架构，以实现异构OS之间数据分发及交互的低复杂性。

本申请第一方面提供了一种数据分发装置，包括框架服务模块、API接口模块、链路协议适配模块和传输映射模块，其中：所述框架服务模块用于调用所述API接口模块、链路协议适配模块或传输映射模块以实现数据的分发；所述API接口模块用于获得发布者OS或订阅者OS的主题信息；所述链路协议适配模块用于对所述传输映射模块解封装获得的各帧数据组装形成车辆数据，所述车辆数据中记载有主题信息，以及基于所述主题信息匹配出所述车辆数据的订阅者OS；所述传输映射模块用于对接收自发布者OS的报文依据该发布者OS的底层传输协议进行解封装获得各帧数据，或将各帧数据依据所述匹配出的所述订阅者OS的底层传输协议进行封装发送。

由上，通过该数据分发装置可以将不同发布者OS发布的主题分发给相应的订阅者OS，实现了各OS(包括异构OS)之间信息的分发与交互。并且通过该数据分发装置进行数据分发，避免了异构OS(包括各发布者OS和订阅者OS)之间的直接交互，降低了各异构OS之间的耦合性、通过低耦合简化了系统的复杂性、由于复杂性的降低也提高了数据分发的可靠性。另一方面，由于低耦合性简化了系统的复杂性，进而也降低了异构OS之间同步开发和最终版本的集成和联调的难度，降低了异构OS应用在车辆电子领域的限制。

作为第一方面的一种可能的实现方式，所述框架服务模块包括数据可靠及完整性功能模块，用于实现所述数据分发装置与所述发布者OS或订阅者OS数据传输中的数据校验或重发。

由上，可以实现数据包传输过程中的可靠性和完整性，解决可能出现的数据包传输出错的情况，提高了数据分发的可靠性。例如，数据包的校验机制包括至少以下之一：奇偶校验、CRC校验、LRC校验、格雷码校验、md5校验和数字签名校验等机制。重发机制包括至少以下之一：数据校验失败重发、数据包传输超时或丢包重发等。

作为第一方面的一种可能的实现方式，所述链路协议适配模块包括：信息库模块，存储有所述发布者OS或订阅者OS的基本信息，所述基本信息包括所述主题信息，用于实现所述基于所述主题信息匹配出所述车辆数据的订阅者OS；数据缓存模块，用于缓存过程数据，所述过程数据包括所述各帧数据和/或所述车辆数据；数据收发模块，用于实现接收所述传输映射模块解析的各帧数据并组装形成车辆数据，或将所述车辆数据分帧发送给所述传输映射模块。

由上，上述各模块为实现链路协议适配模块的一具体方式，上述各模块具体实现了各帧数据的组装形成接收的车辆数据，以及进行主题信息的匹配以建立车辆数据传输的通道，以及还可将车辆数据分帧处理形成要发送给订阅者OS的报文，即实现了将发布者OS发布主题信息分发到对应的订阅者OS。

作为第一方面的一种可能的实现方式，所述信息库模块包括至少以下之一：注册信息模块，用于接收所述发布者OS或订阅者OS的注册信息；心跳信息模块，用于监听所述发布者OS或订阅者OS是否在线；发布/订阅主题模块，用于记录所述发布者OS发布的主题信息或订阅者OS订阅的主题信息；订阅成功/失败模块，用于记录订阅者OS的主题信息的订阅状态。

由上，可以通过这些实现对各通信OS基本信息的(基本信息包括注册信息、心跳信息、发布/订阅的主题、订阅状态等)监听、接收、解析、存储，确保信息库模块记录的内容的正确性与实时性。

作为第一方面的一种可能的实现方式，所述API接口模块还用于创建车辆信息交流表，所述车辆信息交流表用于记录所述发布者OS或订阅者OS的至少以下之一内容：业务类型、所述主题信息、OS类型、订阅者的实体接口及实体接口的关联信息、发布或订阅的工作模式。

由上，通过车辆信息交流表的方式，记录获得的发布者OS或订阅者OS的各类信息，可以根据这些信息灵活实现各类主题信息的分发与交互，例如该分发与交互可匹配发布或订阅的工作模式、可匹配业务类型、OS类型等。

作为第一方面的一种可能的实现方式，还包括：服务质量模块，用于控制所述数据分发装置与所述发布者OS或订阅者OS之间网络通信的质量。

由上，可以实现网络通信的服务质量的可靠性，例如，可以用于实现发布者OS和订阅者之间网络数据流的传输质量及时延控制，又如，可以根据不同的车辆数据类型需求制定特定策略，实现数据流安全可靠的传输质量，以及提高车辆数据传输的灵活性。

本申请第二方面提供了一种车辆电子操作系统的架构，包括：硬件层、基于硬件层上的板级支持包层、基于板级支持包层上的虚拟设备资源层、基于虚拟设备资源层上的微内核层、基于微内核层上的实时操作系统、所述实时操作系统提供的虚拟机管理程序，通过所述虚拟机管理程序运行的各发布者OS或订阅者OS；所述发布者OS或订阅者OS对应车辆的不同业务域；所述实时操作系统内包括第一方面任一所述的数据分发装置。

由上，通过使用含有基于微内核架构的实时系统统一框架的操作系统，可以提升车辆电子虚拟化异构OS之间数据分发及交互的高实时性、高可靠性、OS之间数据收发的非耦合性，简化了车辆电子异构OS的集成难度，使其更加适用于车辆电子操作系统EEA架构整车集中化领域，不但能满足车辆电子操作系统对大数据传输的需求，同时仍能满足SOA架构的需求。

本申请第三方面提供了一种数据分发方法，包括：通过框架服务模块启动框架服务进程；所述框架服务进程监听接收到发布者OS的报文时，调用传输映射模块对接收自发布者OS的报文依据该发布者OS的底层传输协议进行解封装获得各帧数据；所述框架服务进程调用链路协议适配模块，对所述解封装获得的各帧数据组装形成车辆数据，以及基于主题信息匹配出所述车辆数据的订阅者OS；所述框架服务进程调用所述传输映射模块，将各帧数据依据所述匹配出的所述订阅者OS的底层传输协议进行封装发送。

作为第三方面的一种可能的实现方式，还包括：所述框架服务进程调用服务质量模块，用于控制所述数据分发装置与所述发布者OS或订阅者OS之间网络通信的质量。

本申请第四方面提供了一种计算设备，包括：处理器，以及存储器，其上存储有程序指令，所述程序指令当被所述处理器执行时使得所述处理器执行第二方面任一所述的方法。

附图说明

图1是本申请实施例提供的一种车辆电子操作系统架构的示意图；

图2是本申请实施例提供的数据分发装置的示意图；

图3是本申请实施例提供的链路协议适配模块的示意图；

图4是本申请实施例提供的数据分发方法第一实施例的流程图；

图5是本申请实施例提供的数据分发方法第二实施例的流程图；

图6是本申请实施例提供的计算设备的示意图。

应理解，上述结构示意图中，各框图的尺寸和形态仅供参考，不应构成对本发明实施例的排他性的解读。结构示意图所呈现的各框图间的相对位置和包含关系，仅为示意性地表示各框图间的结构关联，而非限制本发明实施例的物理连接方式。

具体实施方式

下面结合附图并举实施例，对本申请提供的技术方案作进一步说明。应理解，本申请实施例中提供的系统结构和业务场景主要是为了说明本申请的技术方案的可能的实施方式，不应被解读为对本申请的技术方案的唯一限定。本领域普通技术人员可知，随着系统结构的演进和新业务场景的出现，本申请提供的技术方案对类似技术问题同样适用。

应理解，本申请实施例提供的数据分发方案，包括数据分发装置及分发方法、计算设备、存储介质、包括该数据分发装置的车辆电子操作系统架构。由于这些技术方案解决问题的原理相同或相似，在如下具体实施例的介绍中，某些重复之处可能不再赘述，但应视为这些具体实施例之间已有相互引用，可以相互结合。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。如有不一致，以本说明书中所说明的含义或者根据本说明书中记载的内容得出的含义为准。另外，本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。为了准确地对本申请中的技术内容进行叙述，以及为了准确地理解本发明，在对具体实施方式进行说明之前先对本说明书中所使用的术语给出如下的解释说明或定义：

1)异构操作系统：指架构中包括有不同类型的操作系统。

2)VxWorks操作系统：是美国WindRiver公司(Wind River System，INC)开发的一种嵌入式实时操作系统。

3)QNX操作系统：是由加拿大QSSL公司(QNX Software System Ltd.)开发的一款微内核实时操作系统。

4)Openwrt：可以被描述为一个嵌入式的Linux发行版。

5)AUTOSAR的全称是AUTomotive Open System Architecture，直译为车辆开放系统架构，简单来说，AUTOSAR是一种开放的软件架构。

6)微内核(Micro kernel)架构：从组成结构上讲，微内核架构包含两类组件：核心系统(core system)和插件模块(plug-in modules)。核心系统负责和具体业务功能无关的通用功能，例如模块加载、模块间通信等。插件模块负责实现具体的业务逻辑，用来向内核系统增强或扩展额外的业务能力。各个插件模块通过核心系统实现通信。

7)阻塞模式：通过某一个状态保证一个对象的任务还没有完成时，不能执行新的任务。使用场景：当有多个线程操作这个对象时，保证对象状态的唯一。

8)协议的枚举：指依次执行系列步骤完成该协议规定的封装或解封装的过程。

9)发布者OS、订阅者OS：本申请中，针对某车辆数据，将提供该车辆数据的OS称为发布者OS，将获取该车辆数据的OS称为订阅者OS。

10)结构体(struct)是一种数据结构，由一系列具有相同类型或不同类型的数据构成的数据集合。

如图1示出了一种车辆电子操作系统架构，为基于微内核架构的实时操作系统，是用于车辆智能化融合的虚拟化异构操作系统的解决方案的架构图，融合了仪表域、信息娱乐域、智能驾驶域、智能底盘域等多业务域。其中，为了便于描述，该架构可以划分为三层，RTOS层、底层、上层。其中，底层为RTOS提供各种资源，底层包括硬件(Hardware)层、板级支持包(Board Support Package，BSP)层、虚拟设备资源层、微内核(Micro kernel)层。上层为各种应用，这些应用可以是运行于各个异构OS内的应用，例如仪表域内的某应用、智能驾驶域内的某应用等。下面参照图1，对该架构进一步详细介绍，具体如下：

硬件(Hardware)层：由各个具体的硬件形成的硬件平台，可以包括单片机、主板、多个SOC形成的集群SOC等。

板级支持包(Board Support Package，BSP)层：是嵌入式系统中介于硬件平台和其上层之间的中间层，主要目的是为了屏蔽底层硬件的多样性，可根据上层的要求完成对硬件的直接操作，以及向上层提供底层硬件信息。

虚拟设备资源层：各个硬件设备的虚拟化层，例如包括各虚拟化CPU(VCPU)、虚拟化网卡、虚拟化内存等。

微内核(Micro kernel)层：微内核负责核心的功能，本申请实施例中，微内核负责的功能主要包括进程的管理、调度，以及进程之间通信。

实时操作系统(Real Time Operating System，RTOS)，指可对数据或事件做出快速处理或响应以完成实时任务的OS。RTOS例如包括QNX、VxWORKs、RTLinux、等操作系统。

虚拟机管理程序(Hypervisor)，在RTOS上可通过Hypervisios实现虚拟机(或称为虚拟化OS)的运行。图1为应用于车辆领域的一个实施例，虚拟机包括有智能座舱域，例如仪表域、娱乐域、MCU域等业务域，每个业务域里有实现相应域功能的应用。

图1中还示出了通过物理网卡接入该RTOS底层硬件系统的其他业务域，例如中央网关域、智能驾驶域、整车控制域等，这些域可基于嵌入式系统实现。这里所述的接入该RTOS底层硬件系统包括通过网卡(图1中示出的ETH表述为网卡)进行通信的方式，在其他一些实施例中，也可以包括通过串口、CAN总线或其他通信方式进行通信，从而实现这些域与RTOS的通信。

上述各域所使用的OS可能不同，例如有的可基于QNX、VxWORKs、RTLinux等，这里以异构OS来表示这种使用不同OS的情况，对应各功能域的异构OS通信时所遵循的标准存在并不统一的情况，尤其涉及通过物理网卡接入该RTOS底层硬件系统与该RTOS进行通信的各异构OS的通信，因此，如何实现基于微内核架构的RTOS的异构OS之间的数据分发，是本申请所要解决的技术问题。

本申请实施例提供的数据分发装置，位于图1示出的RTOS层中，可以应用于例如图1所示的架构中，使用本申请数据分发装置，可满足异构OS之间数据分发及交互需求，并且可满足该交互的高实时性、高可靠性需求。并且，本申请的数据分发装置，实现了各异构OS之间数据收发的低耦合性或非耦合性，简化了异构OS的集成难度，从而更加适用于车辆电子操作系统的整车集中化领域，不但能满足车辆电子操作系统的电子电气架构(Electrical/Electronic Architecture，EEA)架构对大数据传输的需求，也能满足面向服务架构(Service-Oriented Architecture，SOA)的需求。下面将对本申请的实现方案进行详细说明。

为了描述方便，本申请中将图1简化为如图2所示，对本申请实施例提供的数据分发装置进行介绍，如图2所示，该数据分发装置10包括：框架服务(Framework Service)模块11、API接口模块12、链路协议适配模块13、传输映射模块14。其中，

框架服务模块11用于调用所述API接口模块12、链路协议适配模块13或传输映射模块14以实现数据的分发；

API接口模块12用于获得发布者OS或订阅者OS的主题信息；

链路协议适配模块13用于对所述传输映射模块14解封装获得的各帧数据组装形成车辆数据，所述车辆数据中记载有主题信息，以及基于所述主题信息匹配出所述车辆数据的订阅者OS；

传输映射模块14用于对接收自发布者OS的报文依据该发布者OS的底层传输协议进行解封装获得各帧数据，或将各帧数据依据所述匹配出的所述订阅者OS的底层传输协议进行封装发送。

在一些实施例中，该数据分发装置10还可包括服务质量(Quality of Service，QoS)模块15，用于控制所述数据分发装置与所述发布者OS或订阅者OS之间网络通信的质量。

下面结合该数据分发装置10应用于图1的场景，即应用于车辆数据分发的场景，对上述各个模块进一步进行详细介绍：

其中，框架服务模块11具体用于提供其他各个模块的协作关系，并根据该协作关系调用相应模块实现异构OS间的数据分发功能，以及还用于实现数据分发过程中的数据传输的完整性可靠性。

在一些实施例中，该框架服务模块11可具体用于初始化车辆数据的实时分发功能接口，该接口用于实现该数据分发装置10与各异构OS间的车辆数据包的收发，例如从各OS接收车辆数据，以及将车辆数据分发到对应OS中。

在一些实施例中，该框架服务模块11可包含一数据可靠及完整性功能模块，用于实现该数据分发装置与所述发布者OS或订阅者OS数据传输中的数据校验或重发，从而实现数据包传输过程中的可靠性和完整性，解决可能出现的数据包传输出错的情况。在一些实施例中，数据包的校验机制包括至少以下之一：奇偶校验、CRC校验、LRC校验、格雷码校验、md5校验和数字签名校验等机制。在一些实施例中所述重发机制包括至少以下之一：数据校验失败重发、数据包传输超时或丢包重发等。

在一些实施例中，在RTOS启动后的阶段执行该框架服务模块11的初始化操作，包括创建并启动一个名称为Framework Service的框架服务进程，通过该进程实现调用相应其他模块实现异构OS间的数据分发功能。在一些实施例中，该Framework Service进程的工作模式可设置为阻塞模式，以适应于任务复杂、多线程通信的模式。

其中，API接口模块12具体用于通过创建一车辆信息交流表，记录各通信节点之间的通信关系。其中，各通信节点包括各发布者OS或订阅者OS的主题信息。

在一些实施例中，在执行车辆数据通信节点(各通信节点包括各OS)的初始化功能时，该API接口模块12创建上述车辆信息交流表。在一些实施例中，该车辆信息交流表中具体字段可以包括以下部分或全部的内容：

通信的OS的具体业务类型，业务类型包括：智能驾驶域类型、中央网关域类型、仪表域类型、娱乐域类型、整车控制域类型等；

所交流(交流包括发布或订阅)的主题信息，例如车辆的主题信息包括：轮胎气压、手刹信息、安全带、车门、座椅位置、车速信息等；

发布者OS和订阅者OS的OS类型，OS类型包括：QNX、Linux、freeRTOS等；

发布者OS中的发布者和订阅者OS中的订阅者的实体接口，实体接口包括：基于某协议的发送接口、接收接口等，如RS232、串口等；

上述实体接口的关联信息，关联信息包括：结构体包含的参数等，结构体参数可传到协议栈用于解析用；

所建立的发布和订阅的工作模式，工作模式包括：定期发布/订阅、实时发布/订阅、被动发布/订阅、中断的方式发布/订阅等。

其中API接口模块12可将记录的各通信OS的信息的上述部分或全部的内容，传递给链路协议适配模块13中的信息库模块131保存。

其中，API接口创建于各异构OS(各异构OS包括各发布者OS或订阅者OS)中，用于实现统一的车辆数据收发接口，作为异构OS的上层应用与其底层网络驱动交互的出入口，对上层应用屏蔽复杂的底层网络的实现细节。其中，在发布者OS中创建的接口，通过发布者OS进行管理，用于发送车辆数据信息。在订阅者OS中创建的接口，通过订阅者OS进行管理，用于接收车辆数据信息。各异构OS创建API接口后，会将上述列举的部分信息或全部信息提供给本申请的数据分发装置10的API接口模块12，AIP接口模块12根据接收的信息创建所述车辆信息交流表。

其中，链路协议适配模块13具体用于对传输映射模块14解析的报文进行各帧数据的组装形成接收的车辆数据，以及进行主题信息的匹配以建立车辆数据传输的通道，以及还可将车辆数据分帧处理形成要发送给订阅者OS的报文。其中，通过链路协议适配模块13实现了向上层提供统一的链路访问接口及屏蔽底层链路协议细节，这里承上是统一的车辆数据收发接口，启下是传输控制层调用不同的链路协议进行数据的收发操作。在一些实施例中，如图3所示，该链路协议适配模块13包括信息库模块131、数据缓存模块132、数据收发模块133，下面进行介绍：

信息库模块131，存储有所述发布者OS或订阅者OS的基本信息，所述基本信息包括所述主题信息，用于实现所述基于所述主题信息匹配出所述车辆数据的订阅者OS。具体的，通过记录各通信OS的基本信息实现各通信OS的主题信息的匹配，从而建立车辆数据传输的通道(也即实现车辆数据从发布者OS传输到订阅者OS)。在一些实施例中，该信息库模块131可包括：用于接收各通信OS注册信息的注册信息模块1311、用于监听各通信OS是否在线的心跳信息模块1312、用于记录各通信OS的发布/订阅主题模块1313、用于记录订阅状态的订阅成功/失败模块1314，通过这些模块实现对各通信OS基本信息的监听、接收、解析、存储。在一些实施例中，这里的基本信息包括注册信息、心跳信息、发布/订阅的主题、订阅状态。其中，部分信息可以来自于API接口模块12的车辆信息交流表，例如OS的注册信息、发布/订阅的主题等。信息库模块131除了记录的上述基本信息外，还可记录API接口模块12根据车辆信息交流表所提供的表内其他信息。

数据缓存模块132，用于数据分发过程中的过程数据的缓存，缓存的数据可包括接收的发布者OS的报文、对该报文解封装后的各帧车辆数据、组装的完整的车辆数据等过程数据，其可通过车辆的数据接收进程及车辆数据读取进程来存储和获取车辆数据，实现所述数据的缓存和管理。

数据收发模块133，用于数据传输过程中数据收发的执行，例如将解封装的各帧车辆数据接收组装为完成的车辆数据，或将车辆数据分帧处理形成要发送的各报文发送给传输映射模块14。该数据收发模块133支持多线程的收发，例如通过多通道接收多个发布者OS的车辆数据，或向多个订阅者OS分别发送数据。

其中，传输映射模块14具体用于实现对报文进行相应协议的封装或解封装，以实现基于发布者OS或订阅者OS的底层传输协议接收或发送报文。在一些实施例中，传输映射模块14提供了协议枚举填充功能，据此功能，可以使用发布者OS所使用的底层传输协议解析所述报文，获得报文所封装的车辆数据，以及使用订阅者OS所使用的底层传输协议封装所述报文。通过协议的枚举填充完成OS之间的信息交换所需报文的封装和解封装，实现传输数据的接口统一封装功能，避免了上层应用直接调用繁琐的底层链路协议。在一些实施例中，枚举的协议包括例如CAN协议、Link协议、以太网协议等等OS通信所使用的协议。这里的封装包括对报文增加包头等，包头中可包括IP地址、端口号等，解封装则为去掉包头获得封装的报文。

其中，服务质量模块15具体用于控制网络通信的质量。在一些实施例中，可以用于执行发布者OS和订阅者之间网络数据流的传输质量及时延控制，例如，根据不同的车辆数据类型需求制定特定策略，实现数据流安全可靠的传输质量，以及提高车辆数据传输的灵活性。在一些实施例中，上述特定策略例如以下之一或结合：端口流量/限速的控制策略、数据流发布/接收的优先级策略、数据流传输的可靠性优先或传输速率优先策略、数据流传输的有效时间等策略。

如上所述，本申请实施例提供的数据分发装置可应用于图1所示的车辆电子操作系统的架构，基于此，本申请实施例还提供了一种车辆电子操作系统的架构，结合图1和图2所示，该车辆电子操作系统的架构包括硬件层、基于硬件层上的板级支持包层、基于板级支持包层上的虚拟设备资源层、基于虚拟设备资源层上的微内核层、基于微内核层上的实时操作系统、所述实时操作系统提供的虚拟机管理程序，通过所述虚拟机管理程序运行的各发布者OS或订阅者OS；所述发布者OS或订阅者OS对应车辆的不同业务域；还可包括图1示出的非虚拟机的中央网关域、智能驾驶域、整车控制域等；所述实时操作系统内包括上述数据分发装置。各层介绍、各业务域的介绍，具体可参见图1对应实施例的介绍，不再赘述。

本申请还相应的提供了一种数据分发方法的第一实施例，如图4所示，包括以下步骤：

S10：通过框架服务模块启动框架服务进程；

S20：所述框架服务进程监听接收到发布者OS的报文时，调用传输映射模块对接收自发布者OS的报文依据该发布者OS的底层传输协议进行解封装获得各帧数据；

S30：所述框架服务进程调用链路协议适配模块，对所述解封装获得的各帧数据组装形成车辆数据，以及基于主题信息匹配出所述车辆数据的订阅者OS；

S40：所述框架服务进程调用所述传输映射模块，将各帧数据依据所述匹配出的所述订阅者OS的底层传输协议进行封装发送。

其中，所述框架服务进程还可调用服务质量模块，用于控制所述数据分发装置与所述发布者OS或订阅者OS之间网络通信的质量。

下面通过数据分发第二实施例，对本申请的数据分发方法进一步详细说明，该例子中，为应用于车辆领域的实施例，其中，该车辆架构上包括一车身域，对应发布者OS，可提供车速信息，还包括一中控域，对应接收者OS，可接收车速信息并显示，发布者OS、接收者OS可为异构OS，例如分别为linux、freeRTOS，还包括本申请的RTOS，该RTOS中具有本申请的数据分发装置，各OS之间的信息通过本申请的数据分发装置进行数据分发。本申请的数据分发装置接收来自一OS的数据，并转发到另一OS的实现过程，如图5所示，具体包括以下步骤：

S110：在RTOS中，数据分发装置10通过框架服务模块11启动框架服务(FrameworkService)进程，该进程提供了数据转发机制和校验机制，基于该数据转发机制，可调用相应的各模块执行后述的OS之间的数据转发步骤，基于校验机制结合数据的重发机制，实现数据传输的可靠性及完整性。并且，并通过该进程监听车辆数据的实时分发功能接口，即监听是否有相关报文的发布。

S120：当发布者OS，本例中为车身域，发布一车速信息的主题的数据时，发布者OS通过调用对应的该主题的发布接口，即API接口，发送该车速信息的主题。其中，所发布的主题经该发布者OS的底层传输协议(例如CAN协议、或车内网协议等)打包后发送，以传输到RTOS。

S130：RTOS内的本申请的数据分发装置，通过Framework Service进程监听到发布者OS的所发送的报文，调用传输映射模块14对报文进行协议的解封装，解析出报文所封装的车辆数据。

其中，传输映射模块14提供了协议枚举填充功能，据此功能，可以使用发布者OS所使用的底层传输协议解析所述报文，获得报文所封装的车辆数据。

其中，对于解析出的车辆数据，本例中可以由Framework Service进程使用CRC校验对该车辆数据进行完整性、可靠性校验。

S140：对于解析出的车辆数据，由framework Service进程调用链路协议适配模块13进行处理，包括以下子步骤S141-S143：

S141：链路协议适配模块13调用数据收发模块133对解析出的车辆数据进行处理，以得到发布者OS所发布的主题数据。

其中，数据收发模块133的处理可以包括：读取各帧的报文对应的解封装的车辆数据，将各帧车辆数据组装为完整的车辆数据等。

其中，还通过链路协议适配模块13的数据缓存模块132缓存过程数据，过程数据包括接收的发布者OS的报文、对该报文解封装后的车辆数据、组装的数据等。

其中，对于不同发布者OS发布的不同主题的车辆数据，可以由数据收发模块133使用不同的线程(多线程)进行处理，实现多线程的并行处理。

S142：链路协议适配模块13调用信息库模块131，根据信息库模块131中记录的所述主题对应的订阅者OS信息，匹配出订阅者OS以及相关信息。

其中，信息库模块131中记录的上述信息来自本申请数据分发装置10中的API接口模块12所提供的车辆信息交流表。

本例中，上述相关信息包括订阅者OS的订阅主题、发布和订阅的工作模式(配置的定期、实时、被动、中断上报等模式)，并可以根据该工作模式相应触发下一步的执行。

S143：链路协议适配模块13调用数据收发模块133，以执行车辆数据的发送操作，包括将主题数据分为各帧传输给传输映射模块14的处理。又如包括提供给传输映射模块14所述订阅者OS的IP地址、端口号等。

S150：Framework Service进程调用传输映射模块14，由传输映射模块14基于订阅者OS使用的底层传输协议(例如CAN协议、或车内网协议等)，将各帧封装后发出。包括封装的包头中添加上述IP地址和/或端口号等。

S160：订阅者OS通过其底层传输协议接收到所述报文，解析后并通过订阅接口，即API接口，将解析获得的报文数据传给上层相应的应用，本例中订阅者OS对应中控域，则上传给中控域，使中控域获得的作为发布者OS的车身域所发布的车速信息，以进行相应的显示。

另外，在上述数据分发装置10进行数据分发的过程中，还会通过服务质量模块15第所传输的网络数据流进行监控，实现对传输质量及传输时延的控制。

如上为通过本申请数据分发装置实现将一发布者OS发布的主题信息分发给订阅者OS的例子，可见，本申请可满足异构OS之间数据分发及交互需求，并且，由于数据的分发与交互通过本申请数据分发装置进行，并非异构OS之间直接进行，本申请也实现了各异构OS之间数据收发的低耦合性或非耦合性。

图6是本申请实施例提供的一种计算设备900的结构性示意性图。该计算设备可以执行上述方法中的各可选实施例，该计算设备可以是终端，也可以是终端内部的芯片或芯片系统，例如可以是本申请上述异构多核处理器芯片。如图6所示，该计算设备900包括：处理器910、存储器920、通信接口930。

应理解，图6所示的计算设备900中的通信接口930可以用于与其他设备之间进行通信，具体可以包括一个或多个收发电路或接口电路。

其中，该处理器910可以与存储器920连接。该存储器920可以用于存储该程序代码和数据。因此，该存储器920可以是处理器910内部的存储单元，也可以是与处理器910独立的外部存储单元，还可以是包括处理器910内部的存储单元和与处理器910独立的外部存储单元的部件。

可选的，计算设备900还可以包括总线。其中，存储器920、通信接口930可以通过总线与处理器910连接。总线可以是外设部件互连标准(Peripheral ComponentInterconnect，PCI)总线或扩展工业标准结构(Extended Industry StandardArchitecture，EISA)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图6中采用了一条无箭头的线表示，但并不表示仅有一根总线或一种类型的总线。

应理解，在本申请实施例中，该处理器910可以采用中央处理单元(centralprocessing unit，CPU)。该处理器还可以是其它通用处理器、数字信号处理器(digitalsignal processor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现成可编程门阵列(field programmable gate Array，FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。或者该处理器910采用一个或多个集成电路，用于执行相关程序，以实现本申请实施例所提供的技术方案。

该存储器920可以包括只读存储器和随机存取存储器，并向处理器910提供指令和数据。处理器910的一部分还可以包括非易失性随机存取存储器。例如，处理器910还可以存储设备类型的信息。

在计算设备900运行时，所述处理器910执行所述存储器920中的计算机执行指令执行上述方法的任一操作步骤以及其中任一可选的实施例。

应理解，根据本申请实施例的计算设备900可以对应于执行根据本申请各实施例的方法中的相应主体，并且计算设备900中的各个模块的上述和其它操作和/或功能分别为了实现本实施例各方法的相应流程，为了简洁，在此不再赘述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件、或计算机软件与电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。例如，上述各实施例描述的装置、或各装置所包含的各单元或模块，可以是通过进程或软件模块来实现，其中的软件模块可以是按照功能逻辑拆分得到的单元。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时用于执行上述方法，该方法包括上述各个实施例所描述的方案中的至少之一。

本申请实施例的计算机存储介质，可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是，但不限于，电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括、但不限于无线、电线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言或其组合来编写用于执行本申请操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

另外，说明书和权利要求书中的词语“第一、第二、第三等”或模块A、模块B、模块C等类似用语，仅用于区别类似的对象，不代表针对对象的特定排序，可以理解地，在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

在上述的描述中，所涉及的表示步骤的标号，如S110、S120……等，并不表示一定会按此步骤执行，在允许的情况下可以互换前后步骤的顺序，或同时执行。

说明书和权利要求书中使用的术语“包括”不应解释为限制于其后列出的内容；它不排除其它的元件或步骤。因此，其应当诠释为指定所提到的所述特征、整体、步骤或部件的存在，但并不排除存在或添加一个或更多其它特征、整体、步骤或部件及其组群。因此，表述“包括装置A和B的设备”不应局限为仅由部件A和B组成的设备。

本说明书中提到的“一个实施例”或“实施例”意味着与该实施例结合描述的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在本说明书各处出现的用语“在一个实施例中”或“在实施例中”并不一定都指同一实施例，但可以指同一实施例。此外，在一个或多个实施例中，能够以任何适当的方式组合各特定特征、结构或特性，如从本公开对本领域的普通技术人员显而易见的那样。

注意，上述仅为本申请的较佳实施例及所运用技术原理。本领域技术人员会理解，本申请不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本申请的保护范围。因此，虽然通过以上实施例对本申请进行了较为详细的说明，但是本申请不仅仅限于以上实施例，在不脱离本申请构思的情况下，还可以包括更多其他等效实施例，均属于本申请保护范畴。

Claims (8)

1.一种数据分发装置，其特征在于，包括框架服务模块、API接口模块、链路协议适配模块和传输映射模块，其中：

所述框架服务模块用于调用所述API接口模块、链路协议适配模块或传输映射模块以实现数据的分发；

所述API接口模块用于获得发布者OS或订阅者OS的主题信息；所述API接口模块还用于创建车辆信息交流表，所述车辆信息交流表用于记录所述发布者OS或订阅者OS的至少以下之一内容：业务类型、所述主题信息、OS类型、订阅者的实体接口及实体接口的关联信息、发布或订阅的工作模式；

所述链路协议适配模块用于对所述传输映射模块解封装获得的各帧数据组装形成车辆数据，所述车辆数据中记载有主题信息，以及基于所述主题信息匹配出所述车辆数据的订阅者OS；

所述传输映射模块用于对接收自发布者OS的报文依据该发布者OS的底层传输协议进行解封装获得各帧数据，或将各帧数据依据所述匹配出的所述订阅者OS的底层传输协议进行封装发送；

所述链路协议适配模块包括：

信息库模块，存储有所述发布者OS或订阅者OS的基本信息，所述基本信息包括所述主题信息，用于实现所述基于所述主题信息匹配出所述车辆数据的订阅者OS；

数据缓存模块，用于缓存过程数据，所述过程数据包括所述各帧数据和/或所述车辆数据；

数据收发模块，用于实现接收所述传输映射模块解析的各帧数据并组装形成车辆数据，或将所述车辆数据分帧发送给所述传输映射模块。

2.根据权利要求1所述的装置，其特征在于，所述框架服务模块包括数据可靠及完整性功能模块，用于实现所述数据分发装置与所述发布者OS或订阅者OS数据传输中的数据校验或重发。

3.根据权利要求1所述的装置，其特征在于，所述信息库模块包括至少以下之一：

注册信息模块，用于接收所述发布者OS或订阅者OS的注册信息；

心跳信息模块，用于监听所述发布者OS或订阅者OS是否在线；

发布/订阅主题模块，用于记录所述发布者OS发布的主题信息或订阅者OS订阅的主题信息；

订阅成功/失败模块，用于记录订阅者OS的主题信息的订阅状态。

4.根据权利要求1所述的装置，其特征在于，还包括：服务质量模块，用于控制所述数据分发装置与所述发布者OS或订阅者OS之间网络通信的质量。

5.一种车辆电子操作系统的架构，其特征在于，包括：

硬件层、基于硬件层上的板级支持包层、基于板级支持包层上的虚拟设备资源层、基于虚拟设备资源层上的微内核层、基于微内核层上的实时操作系统、所述实时操作系统提供的虚拟机管理程序，通过所述虚拟机管理程序运行的各发布者OS或订阅者OS；所述发布者OS或订阅者OS对应车辆的不同业务域；

所述实时操作系统内包括权利要求1至4任一项所述的数据分发装置。

6.一种数据分发方法，其特征在于，包括：

通过框架服务模块启动框架服务进程；

所述框架服务进程监听接收到发布者OS的报文时，调用传输映射模块对接收自发布者OS的报文依据该发布者OS的底层传输协议进行解封装获得各帧数据；

所述框架服务进程调用链路协议适配模块，对所述解封装获得的各帧数据组装形成车辆数据，以及基于主题信息匹配出所述车辆数据的订阅者OS；

所述框架服务进程调用所述传输映射模块，将各帧数据依据所述匹配出的所述订阅者OS的底层传输协议进行封装发送；

所述框架服务进程调用所述传输映射模块，将各帧数据依据所述匹配出的所述订阅者OS的底层传输协议进行封装发送包括：

链路协议适配模块调用数据收发模块来实现接收所述传输映射模块解析的各帧数据并组装形成车辆数据，或将所述车辆数据分帧发送给所述传输映射模块；

链路协议适配模块调用数据缓存模块缓存过程数据，所述过程数据包括所述各帧数据和/或所述车辆数据；

链路协议适配模块调用信息库模块来匹配出订阅者OS以及相关信息，所述信息库模块存储有所述发布者OS或订阅者OS的基本信息，所述基本信息包括所述主题信息，用于实现所述基于所述主题信息匹配出所述车辆数据的订阅者OS；

其中，所述信息库模块中记录的发布者OS或订阅者OS的基本信息来自API接口模块，所述API接口模块还用于创建车辆信息交流表，所述车辆信息交流表用于记录所述发布者OS或订阅者OS的至少以下之一内容：业务类型、所述主题信息、OS类型、订阅者的实体接口及实体接口的关联信息、发布或订阅的工作模式。

7.根据权利要求6所述的方法，其特征在于，还包括：

所述框架服务进程调用服务质量模块，用于控制数据分发装置与所述发布者OS或订阅者OS之间网络通信的质量。

8.一种计算设备，其特征在于，包括：

处理器，以及

存储器，其上存储有程序指令，所述程序指令当被所述处理器执行时使得所述处理器执行权利要求6或7所述的数据分发方法。