掌桥专利:专业的专利平台
掌桥专利
首页

舱驾融合的数据传输方法、系统、装置、设备及介质

文献发布时间:2024-04-18 19:58:53


舱驾融合的数据传输方法、系统、装置、设备及介质

技术领域

本申请属于智能驾驶技术领域,尤其涉及一种舱驾融合的数据传输方法、系统、装置、电子设备及计算机可读存储介质。

背景技术

当前,车辆制造领域中,智能座舱和智能驾驶成为了汽车的重要功能域,它们分别涉及到人与车、车与环境的交互,如何在车辆驾驶过程中更加安全,在座舱体验中更加舒适一直是制造商与驾乘人员所共同关注的焦点。

在传统的汽车电子电气架构中,使用域控(汽车域控制器,是一种集成了多种功能的电子控制单元(ECU,Electronic Control Unit))管理和控制车辆的各种系统,智能驾驶和智能座舱设计为两个不同的域控,其相互之间通过多条不同种类的数据总线相互关联(如控制器局域网总线、面向媒体的系统传输总线等),常见的一种设计方式如图1所示,通过将拍摄设备、自动驾驶域控、座舱域控以及屏幕线性级联,当座舱域需要进行车内屏幕的车辆影像输出时,首先向直接与拍摄设备相连的自动驾驶域控请求视频信息,然后自动驾驶域控再通过不同的线路逐一向座舱域控反馈各种数据。

这种方式存的问题包括:多条数据总线需要多条硬线连接,增加了线束的数量和重量;增加了设备的复杂度和开发难度的同时数据总线的带宽和时延受到限制,影响了数据传输的效率和实时性。

发明内容

本申请旨在提供一种舱驾融合的数据传输方法、系统、装置、电子设备及计算机可读存储介质,至少解决了智能驾舱设计架构中由于传统双电子控制单元之间的多数据总线需求而造成的多硬线连接、设备复杂度高、数据传输效率低的问题。

第一方面,本申请实施例公开了一种舱驾融合的数据传输方法,包括:

获取视频并行数据,并将所述视频并行数据存储到共享内存片区;

通过运行在虚拟总线程序中的数据提供服务,将所述视频并行数据自所述共享内存片区并行分发至第一虚拟机及第二虚拟机中;

通过运行在所述第一虚拟机中的自动驾驶程序,根据所述视频并行数据执行自动驾驶;

通过运行在所述第二虚拟机中的座舱域程序,根据所述视频并行数据及预存于所述共享内存片区的视频参数数据,生成合成视频流并输出。

第二方面,本申请实施例还公开了一种舱架融合的数据传输系统,包括:电子控制单元、显示屏、多个拍摄设备;

电子控制单元中运行有第一虚拟机及第二虚拟机;电子控制单元还运行有虚拟总线程序,虚拟总线程序用于提供数据提供服务,第一虚拟机中运行有自动驾驶程序,第二虚拟机中运行有座舱域程序;

所述电子控制单元用于:

获取视频并行数据,并将视频并行数据存储到电子控制单元的共享内存片区中;所述视频并行数据包括由多个拍摄设备分别拍摄的外部视频流拼接生成的视频流;

通过所述数据提供服务,将视频并行数据自所述共享内存片区并行调用分发至第一虚拟机及第二虚拟机中;

通过运行在第一虚拟机中的自动驾驶程序,根据所述视频并行数据执行自动驾驶;

通过运行在第二虚拟机中的座舱域程序,根据所述视频并行数据及预存于所述共享内存片区的视频参数数据,生成合成视频流并在显示屏展示。

第三方面,本申请实施例还公开了一种舱驾融合的数据传输装置,包括:

视频解串模块,用于获取视频并行数据,并将视频并行数据存储到共享内存片区;

数据服务订阅模块,用于通过运行在虚拟总线程序中的数据提供服务,将视频并行数据自所述共享内存片区并行调用分发至第一虚拟机及第二虚拟机中;

自动驾驶模块,用于通过运行在第一虚拟机中的自动驾驶程序,根据所述视频并行数据执行自动驾驶;

视频串流模块,用于通过运行在第二虚拟机中的座舱域程序,根据所述视频并行数据及预存于所述共享内存片区的视频参数数据,生成并输出合成视频流。

第四方面,本申请实施例还公开了一种电子设备,包括:处理器、用于存储所述处理器可执行指令的存储器;

所述程序或指令被所述处理器执行时实现如第一方面所述的方法的步骤。

第五方面,本申请实施例还公开了一种计算机可读存储介质,其特征在于,当所述计算机可读存储介质中的指令由电子设备的处理器执行时,所述程序或指令被处理器执行时实现如第一方面所述的方法的步骤。

综上,在本申请实施例中,通过在电子控制单元上建立了分别运行有自动驾驶程序的第一虚拟机与座舱域程序的第二虚拟机,并将外部获取的视频并行数据存储于共享内存中,两部虚拟机分别通过设置于电子控制单元的虚拟总线,调用视频并行数据,抛弃了现有技术中将自动驾驶程序与座舱程序运行于实体处理器,再通过实体总线相互数据通信的方式。由此,基于本申请实施例的方法,消除了硬线连接、使得设备开发软件化并提高了整体的传输效率,解决了智能驾舱设计架构中由于传统双电子控制单元之间的多数据总线需求而造成的多硬线连接、设备复杂度高、数据传输效率低的问题。

附图说明

在附图中:

图1是现有技术中车辆舱驾自动驾驶域控与座舱域控的系统架构图;

图2是本实施例提供的一种基于工业设备的事件提醒方法的步骤流程图;

图3为申请实施例提供的另一种基于工业设备的事件提醒方法的系统架构图;

图4为本申请实施例提供的根据本申请的方法倒车的示意图;

图5是本申请实施例提供的另一种基于工业设备的事件提醒方法的步骤流程图;

图6是本申请实施例提供的一种基于工业设备的事件提醒方法的核心系统架构图;

图7是本申请实施例提供的一种基于工业设备的事件提醒方法的流程池;

图8是本申请实施例提供的一种舱驾融合的数据传输装置框图;

图9是本申请实施例提供的一个实施例的电子设备的框图;

图10是本申请实施例提供的另一个实施例的电子设备的框图。

具体实施方式

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

本申请的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象,而不用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施,且“第一”、“第二”等所区分的对象通常为一类,并不限定对象的个数,例如第一对象可以是一个,也可以是多个。此外,说明书以及权利要求中“和/或”表示所连接对象的至少其中之一,字符“/”,一般表示前后关联对象是一种“或”的关系。

图2是本实施例提供的一种基于工业设备的事件提醒方法,方法应用于客户端。

方法可以包括如下步骤:

步骤101,获取视频并行数据,并将所述视频并行数据存储到共享内存片区。

参考图3所示的本申请实施例提供的一种舱架融合的数据传输系统,包括:

电子控制单元、显示屏、多个拍摄设备;

电子控制单元中运行有第一虚拟机及第二虚拟机;电子控制单元还运行有虚拟总线程序,虚拟总线程序用于提供数据提供服务,第一虚拟机中运行有自动驾驶程序,第二虚拟机中运行有座舱域程序;

所述电子控制单元用于:获取视频并行数据,并将视频并行数据存储到电子控制单元的共享内存片区中;所述视频并行数据包括由多个拍摄设备分别拍摄的外部视频流拼接生成的视频流;通过所述数据提供服务,将视频并行数据自所述共享内存片区并行调用分发至第一虚拟机及第二虚拟机中;通过运行在第一虚拟机中的自动驾驶程序,根据所述视频并行数据执行自动驾驶;通过运行在第二虚拟机中的座舱域程序,根据所述视频并行数据及预存于所述共享内存片区的视频参数数据,生成合成视频流并在显示屏展示。

在本申请实施例中,首先破除了传统技术方案中数据传输线性级联的模式,在传统的舱驾技术方案中,将两个域控分别独立,因此不设置专用的存储单元,但如此一来又需要设置针对存储单元的控制单元,成本代价过高。而是使用存储单元设置在其中一个域控之上,另一个域控进行请求调用的代用模式,但这样的主要问题在于请求方的域控无法完全独立建立数据通信,因而受制于另一域控。比如说,在现实情况下,如图1所示,为了优先保证驾驶安全,两个域控的优先级会设置驾驶域控更高,因此在两个独立域控的情况下座舱域控需要经过视频请求、数据获取(图1中自动驾驶域控指向座舱域控的全部过程)、数据处理、屏幕输出的过程,如此一来一旦自动驾驶域控有任何问题,如未开机、延迟、死机登问题,将同时意味着座舱域控的失灵。因此本申请实施例设计了专门的共享内存片区,将获取到的视频并行数据进行单独存储,使得域控之间运行完全独立。

示例地,在一个实施例中,为了使两个域控可以相互独立的获取相关的视频数据,本申请实施例将外部视频同时多路获取,通过数据重构(如拼接、变换等)的方法获取到视频并行数据存放在一个单独设立的共享内存片区。在上述过程中,视频并行数据包括但不限于:二维图片和/或三维全向的图片,或者由这些图片作为画面帧构成的视频,或者多路同步的原始视频流数据包;需要强调的是,本申请中所述的“全向”指的是不低于以观测者顶视方向为轴,360度旋转所得的视界范围。

示例地,在另一个实施例中,所述共享内存片区可以采用任何可读写设备,但为了适用存储数据量本身较大的视频类数据,建议选取容量大、读写速率高的可用于数据寄存的设备,实际使用时可以根据成本选择包括但不限于以下的类型:如动态随机存取存储器(DRAM)产品类型的双倍速率同步动态随机存储器(DDR,Double Data Rate SDRAM)/低功耗双倍速率同步动态随机存储器(LPDDR,Low Power Double Data Rate SDRAM)等,或快闪记忆体(NAND FLASH)类型的多媒体卡内嵌式存储器(eMMC,Embedded Multi Media Card)/固态硬盘(SSD,Solid State Disk)等。

示例地,在再一个实施例中,所述视频并行数据包括由多个拍摄设备分别拍摄的外部视频流拼接生成的视频流,同时也保留了由多个拍摄设备分别拍摄的外部视频流本身,通过这样的方式,使得当第一虚拟机中的自动驾驶车与第二虚拟机中的座舱域程序使用不同的数据接口、程序版本或程序类型的情况下,对数据源的选择方式更加灵活。

步骤102,通过运行在虚拟总线程序中的数据提供服务,将所述视频并行数据自所述共享内存片区并行分发至第一虚拟机及第二虚拟机中。

本步骤中涉及的系统架构与上述步骤101实现过程类似,此处不再赘述。

如同步骤101中所提及的,现有技术中控域关系明显缺点即为使用了线性级联的设备,因此在本申请实施例中,基于步骤101的步骤,通过建立两个虚拟机,以确实实现两个独立功能域控之间的并联关系,以解决原技术方案中名义上控域独立,实质其中一方受制于另一方的情况;与此同时通过虚拟总线技术将两个虚拟机分别设置于同一台高速计算机(HPC,High performance computing)上,如此一来,就可以将步骤101中所述的共享内存片区同样设置其中,以进一步精简设备。

示例地,在本步骤相关的一个实施例中,设置第一虚拟机以及第二虚拟机,其中第一虚拟机用以替代原技术方案中的自动驾驶域控,第二虚拟机用以替代原技术方案中的座舱域控,而所述的两个虚拟机也均可以分别根据自身需求选择合适的软件系统。常见地,第一虚拟机作为自动驾驶域控,可以选择包括但不限于黑莓旗下一款商业实时操作系统QNX(QuickUNIX)系统、Linux(一种开源操作系统)等具有较强稳定性的系统,对于注重安全性的自动驾驶域控较为适合;而第二虚拟机作为座舱域控,更为注重对外接口的通用性、便捷性以及前端开发难度,因此可以选择包括Android(安卓系统)、Windows(视窗操作系统)在内的图形功能较强的系统。

步骤103,通过运行在所述第一虚拟机中的自动驾驶程序,根据所述视频并行数据执行自动驾驶。

本步骤中涉及的系统架构与上述步骤101实现过程类似,此处不再赘述。

本步骤针对于第一虚拟机,在一个实施例中,通过在第一虚拟机中提前写入的自动驾驶程序以实现自动驾驶功能,通过将自动驾驶功能相关程序脱离自动驾驶域控的虚拟机本身,使自动驾驶程序得以简单快速的迭代升级。

示例地,如图4所示,在本步骤的一个实施例中,自动驾驶程序通过获取视频并行数据分析获取当前车辆401四周的道路402、障碍物404、地面划线403等信息即可实现车辆的倒车行为。

步骤104,通过运行在所述第二虚拟机中的座舱域程序,根据所述视频并行数据及预存于所述共享内存片区的视频参数数据,生成合成视频流并输出。

本步骤针对于第二虚拟机,在一个实施例中,座舱域的一个重要功能体现在于影音功能,基于这一功能座舱域可以用于实现车辆状态的输出和警报,因此可以在第二虚拟机内植入座舱域程序以实现相关功能。

示例地,如图4所示,在本步骤的一个实施例中,自动驾驶程序通过获取视频并行数据分析获取当前车辆401四周的道路402、障碍物404、地面划线403等信息,并整合相关的视频并行数据,即可在车辆的倒车时生成倒车模拟俯视图。

综上,在本申请实施例中,通过在电子控制单元上建立了分别运行有自动驾驶程序的第一虚拟机与座舱域程序的第二虚拟机,并将外部获取的视频并行数据存储于共享内存中,两部虚拟机分别通过设置于电子控制单元的虚拟总线,调用视频并行数据,抛弃了现有技术中将自动驾驶程序与座舱程序运行于实体处理器,再通过实体总线相互数据通信的方式。由此,基于本申请实施例的方法,消除了硬线连接、使得设备开发软件化并提高了整体的传输效率,解决了智能驾舱设计架构中由于传统双电子控制单元之间的多数据总线需求而造成的多硬线连接、设备复杂度高、数据传输效率低的问题。

图5为申请实施例提供的另一种基于工业设备的事件提醒方法,参照图5,方法可以包括如下步骤:

步骤201,获取多路外部视频流,以及通过所述自动驾驶程序对外部视频流进行标定数据的提取;

本步骤中涉及的系统架构与上述步骤101实现过程类似,此处不再赘述。

标定数据即为数据分析时用以作为基准的数据,在本申请的一个实施例中,视频数据的标定值不通过人为的直接设置,而是通过在设备初始化或开机后对输入视频的一个采样判断获得。

示例地,如图3所示,在本申请的一个实施例中,拍摄设备具有多个,因此传入电子控制单元之前的外部视频流也有多路,这在未来被第一虚拟机以及第二虚拟机调用的时候具有一定的不方便性,因此我们通过设置解串器对外部视频流进行处理,而数据处理前为了可以使数据之间相互自洽,解串器就会在设备初始化时以初始数据作为基准,即获取标定数据,作为后续数据处理的参考量。本实施例中,同时也给出了两个虚拟机分别获取数据的具体路径,具体如下表所示:

表1

表1中,订阅方指的是需要获取对应数据的主体应用,即自动驾驶程序与座舱域程序;主题共包括:视频并行数据、标定参数、初始化结果、故障状态以及占用状态,指的是订阅方所请求的具体数据内容,所述的五种主题中,除去视频并行数据的四种数据即为图3中的视频参数;而提供方(数据提供服务)为订阅方提供对应数据的寻址服务。

步骤202,通过所述自动驾驶程序利用标定数据,对所述多路外部视频流进行拼接,获得视频并行数据,并将所述视频并行数据存储到共享内存片区。

本步骤中涉及的系统架构与上述步骤101实现过程类似,此处不再赘述。

作为步骤201的后续步骤,自动驾驶程序利用标定数据即可将获取的多路视频数据完成拼接获得视频并行数据。

示例地,在一些实施例中,图4所示为车辆401通过四个拍摄设备405获得全向画面帧的过程,图中任意两个相邻虚线所夹的范围为此区域内拍摄设备的标定视界406的边界,然而实际上为了保证数据完整性,拍摄设备的实际摄像范围407会略大于标定视界,因此设置了两个相邻虚线所夹的范围为标定视界406,而标定视界406的边界参数即为标定参数,在实际拼接图像时只需要对通过实际摄像范围407所获得的图片帧按照标定参数进行裁切,就可以获得四张邻接无误差的同步照片,然后只要按照临界边对四张同步照片进行直接拼接就可以获得最终的视频并行数据;这种标定数据一般只有在设备有较大变化的情况下才需要重置。

在一些实施例中,如图6所示为本申请实施例提供的一种基于工业设备的事件提醒方法的核心系统架构图,包括:用于存储视频并行数据以及视频参数的共享内存片区,用以运行自动驾驶程序的第一虚拟机,用以运行座舱域程序的第二虚拟机,用以提供数据提供服务以及各模块间连接的虚拟总线程序,以及用以对第一虚拟机、第二虚拟机,以及数据提供服务进行资源调配管理的资源管理虚拟机;基于上述架构,在步骤203-205相关的实施例中,配置有资源管理虚拟机以实现虚拟机之间的资源占用问题。

示例地,在一个实施例中,资源管理虚拟机使用QNX系统,借助其核心提供的4种服务:进程调度、进程间通信、底层网络通信和中断处理,其进程在独立的地址空间运行。实现为协作的用户进程,并借助其小巧的占用且运行速度极快实现虚拟机的管理。

以下将分别对步骤203-205进行逐一说明:

本步骤中涉及的系统架构与上述步骤101实现过程类似,此处不再赘述。

步骤203,响应于所述第一虚拟机及所述第二虚拟机的内核占用请求,通过资源管理虚拟机获取预设的索引表,以及当前实体内核的占用情况;所述索引表记录了实体内核与虚拟内核之间的对应关系;

在本步骤相关的实施例中,所述索引表实际上决定了资源分配的具体调度规则,其具体内容可以基于所述资源管理虚拟机的预设,也可以基于现场运算匹配获得的结果可以得到设备资源分配时的具体内核分配策略。

示例地,在上述QNX系统相关的实施例中,利用QNX系统强大的资源调度能力,则可以将内核分配策略完全交予系统实现;反之若资源管理虚拟机的功能较为落后,则可以预设索引表以减少处理器负担。如某电子设备中目前具有16个实体内核,运行有虚拟机一和虚拟机二,两个虚拟机分别设定有32个虚拟内核,索引表记录了实体内核与虚拟内核的分配比为3:1;那么在最初的机器周期(计算机处理器完成一个基本操作所需要的时间)时假设虚拟机一请求使用32个虚拟内核以完成一个耗时两个机器周期的命令,同时虚拟机二的请求使用16个虚拟内核以完成一个耗时一个机器周期的命令;那么此机器周期实际内核的分配即为:虚拟机1占用内核12个,虚拟机二占用内核4个。

步骤204,根据当前实体内核的占用情况,确定当前为空闲的目标实体内核;

本步骤中涉及的系统架构与上述步骤101实现过程类似,此处不再赘述。

本步骤为步骤203的后续步骤,在本步骤相关实施例中,在实际分配内核时需要先行调取内核占用的表格以为后续步骤做实际分配的准备。

示例地,接步骤203的实施例,在步骤203实施例结尾(第二个机器周期),由于上一机器周期虚拟机一请求的命令耗时两个机器周期,虚拟机二请求的命令耗时一个机器周期,因此在第二个机器周期内资源管理虚拟机所获取到的实际内核占用情况即为:实体内核占用情况为分配给虚拟机一的12个实体内核继续被占用,而分配给虚拟机二的4个虚拟内核已经被释放。

步骤205,通过资源管理虚拟机,按照记录了所述实体内核与所述虚拟内核之间的对应关系的索引表,确定与所述目标实体内核对应的目标虚拟内核,并将所述目标虚拟内核分配给所述第一虚拟机及所述第二虚拟机。

本步骤中涉及的系统架构与上述步骤101实现过程类似,此处不再赘述。

本步骤为步骤204的后续步骤,基于步骤203与步骤204的相关数据信息,资源管理虚拟机则可以合理分配实体内核,在不破坏优先级的前提下尽可能提升虚拟内核运算平均时长。

示例地,接步骤204的实施例,此时虚拟机一剩余的请求数为32-12=20个,虚拟机二剩余的请求数为16-4=12个,而实际空闲的虚拟内核为4个,又由于索引表记录的实体内核与虚拟内核的分配比依然为3:1,此时分配给虚拟机一的实体内核即为3个,分配给虚拟机二的虚拟内核为1个;当进入第三个机器周期内,此时全部的实体内核被释放,而剩余的请求内核数分别为20-3=17个,12-1=11个;此时则依然根据实体内核与虚拟内核的分配比分配虚拟机一占用12个,虚拟机二占用4个…由此即可重复步骤203-205,直到所有的内核占用请求被完成。

步骤206,通过运行在虚拟总线程序中的数据提供服务,将所述视频并行数据自所述共享内存片区并行分发至第一虚拟机及第二虚拟机中;

本步骤的实现方式与上述步骤102实现过程类似,此处不再赘述。

步骤207,通过运行在所述第一虚拟机中的自动驾驶程序,根据所述视频并行数据执行自动驾驶;

本步骤的实现方式与上述步骤103实现过程类似,此处不再赘述。

可选地,

步骤207还包括以下子步骤:

子步骤2071,根据所述视频并行数据,检测当前车辆所处环境中的驾驶对象;

本步骤为自动驾驶程序执行命令的命令确认步骤,如图4所示,在一个实施例中,当车辆的执行目标为倒车的情况下,则首先需要通过视频确定倒车的具体位置。

子步骤2072,根据所述驾驶对象,初始化驾驶路径;

作为子步骤2071的后续步骤,步骤2072将根据视频并行数据具体推算车辆与驾驶对象的具体相对位置,再根据车辆相对位置与预设的自动驾驶路径模版推算一个合理化的驾驶路径。

子步骤2073,根据所述视频并行数据,确定处于所述初始路径中的障碍物;

作为子步骤2072的后续步骤,在正式开始自动驾驶之前自动驾驶程序还同时需要检测获取驾驶路径上的障碍物信息。

子步骤2074,当根据所述障碍物确定车辆无需绕行时,根据驾驶路径执行自动驾驶;

如图4所示,在本步骤的一个实施例中,自动驾驶程序通过获取视频并行数据分析获取当前车辆401四周的道路402及地面划线403信息进一步推算出车辆距离目标地点的实际距离,进一步通过确认到的障碍物404的实际情况满足行进路线执行的相关阈值(如障碍物较远,不足以影响自动驾驶命令执行),进而即可推算出车辆401的行进路线。

子步骤2075,当根据所述障碍物确定车辆需要绕行时,根据所述视频并行数据调整驾驶路径,根据调整后的驾驶路径自动驾驶;

如图4所示,在本步骤的一个实施例中,自动驾驶程序通过获取视频并行数据分析获取当前车辆401四周的道路402及地面划线403信息进一步推算出车辆距离目标地点的实际距离,进一步通过确认到的障碍物404的实际情况满足行进路线执行的相关阈值(如障碍物较近,需要通过执行前进命令以调整车辆姿态),进而即可推算出车辆401的行进路线。

子步骤2076,当根据所述障碍物确定车辆无法绕行时,执行刹车或减速停车指令;

如图4所示,在本步骤的一个实施例中,自动驾驶程序通过获取视频并行数据分析获取当前车辆401四周的道路402及地面划线403信息进一步推算出车辆距离目标地点的实际距离,进一步通过确认到的障碍物404的实际情况不满足行进路线执行的相关阈值(如障碍物太大,无法通过调整姿态执行自动驾驶),进而通过提示告知驾驶员并执行刹车或减速停车指令。

子步骤2074-2076为子步骤2073的后续可选步骤,其分别定义了当确立了驾驶路径上的障碍物情况后,将择一的根据实际情况执行子步骤2074-2076。

步骤208,通过运行在所述第二虚拟机中的座舱域程序,根据所述视频并行数据及预存于所述共享内存片区的视频参数数据,生成合成视频流并输出。

本步骤的实现方式与上述步骤104实现过程类似,此处不再赘述。

可选地,步骤208还包括以下子步骤:

子步骤2081,通过所述运行在第二虚拟机中的座舱域程序,将所述视频并行数据逐帧缩放,得到缩放视频;

由于车辆的实际显示显示屏尺寸有限,因而拍摄设备的分辨率能力远高于显示屏的输出分辨率,因此在输出显示屏之前可以对视频并行数据进行缩放处理,缩放方式包括但不限于剪切,缩放,色域转换,图像拼接等,这样将可以将后续的串流及视频流输出的设备负担降低,因而压低相关的设备需求以节约实际成本。

示例地,如图7所示,在本申请的一个实施例中,设备实际运行时,数据的传输在拍摄设备、电子控制单元,以及显示屏之间进行:多个拍摄设备同步获取多路视频数据之后基于差分信号(LVDS,Low-VoltageDifferential Signaling)线路传输至电子控制单元,所述电子控制单元上设置有解串器,对外部视频流进行解串以获得视频并行数据,并存储至共享内存片区,其后自动驾驶程序与座舱域程序相互分别独立地自数据服务订阅模块订阅视频流数据,其中座舱域程序还会直接从共享内存片区读取预存的视频参数数据,在分别获取了需要的数据之后,自动驾驶程序执行自动驾驶功能,而座舱域程序则将通过自身功能生成的视频素材合成拼接,最后基于LVDS线路输出至显示屏;视频输入输出使用的LVDS协议,作为一种低功耗、低误码率、低串扰和低辐射的差分信号技术,缩放后的视频将可以进一步降低设备功耗。

子步骤2082,通过所述座舱域程序,使用所述视频参数数据对缩放视频进行简化处理,获得至少一种视频素材;所述视频素材包括:二维视图、三维视图、车模视图、辅助线视图、雷达视图中的一种或多种;

根据用户实际需求,根据视频并行数据,座舱域程序还可以分析生成上述全部的视频素材。

示例地,如图4所示,在图中倒车车辆的后视视野里,可以随时测算车辆距离道沿、后方车辆的距离,则根据距离均可在车辆二维视图模版、三维视图模版、车模视图模版里增加相关图片素材以合成二维视图、三维视图、车模式图。

子步骤2083,响应于展示指令,根据至少一种视频素材生成所述合成视频流。

在实际情况下,用户往往只会选择部分视频素材作为展示,此时只需根据选择将子步骤2082生成的视频素材通过串流器合成为一个单路的视频流即可最终输出。

可选地,步骤208还包括以下子步骤:

子步骤2084,根据初始化结果、占用状态、故障状态,进行车辆当前状态的判断,获得判断结果;

在本子步骤相关的实施例中,座舱域程序除去车辆驾驶状态的演示功能之外,还具备车辆错误警报的功能,类似于步骤201,座舱域程序也可从视频并行数据中获得或推算获得拍摄设备的初始化结果、占用状态、故障状态,并进一步的进一步推算获取车辆的真实故障状态。

子步骤2085-2086为子步骤2084的后续可选步骤,在推算出车辆的故障状态下,则会根据实际故障情况给出反馈,当有故障的情况下则会给出警报,反之则会合成相关视频信息以输出。

子步骤2085,在判断结果为异常的情况下,进行故障告警;

在本申请的全体过程中,拍摄设备的输入信息作为唯一信息输入源,其重要性很高,因此在数据异常的情况下需要即行进行报警判断。

如图4所示,在本申请的一个实施例中,若四个拍摄设备405的任意一个存在遮挡、数据延迟等情况均会触发报警提示。

子步骤2086,在判断结果为正常的情况下,通过所述座舱域程序,根据所述视频并行数据及预存于所述共享内存片区的视频参数数据,生成合成视频并行并输出。

作为子步骤2085的互斥步骤,当判断无数据异常的情况下则会正常执行其他指令。

可选地,所述第一虚拟机和/或第二虚拟机为运行在资源管理虚拟机的嵌入式虚拟机。

基于步骤102的实施例,当第二虚拟机结构简化,并已经明确确定需要和第一虚拟机共同开启的情况下,为了进一步节省资源占用,可以将第二虚拟机以嵌套的形式启动于第一虚拟机之中,这在车辆长期运行的情况下将可以进一步节约能源。

参考图3,其示出了本申请实施例提供的一种舱架融合的数据传输系统,包括:电子控制单元、显示屏、多个拍摄设备;

电子控制单元中运行有第一虚拟机及第二虚拟机;电子控制单元还运行有虚拟总线程序,虚拟总线程序用于提供数据提供服务,第一虚拟机中运行有自动驾驶程序,第二虚拟机中运行有座舱域程序;

所述电子控制单元用于:

获取视频并行数据,并将视频并行数据存储到电子控制单元的共享内存片区中;所述视频并行数据包括由多个拍摄设备分别拍摄的外部视频流拼接生成的视频流;

通过所述数据提供服务,将视频并行数据自所述共享内存片区并行调用分发至第一虚拟机及第二虚拟机中;

通过运行在第一虚拟机中的自动驾驶程序,根据所述视频并行数据执行自动驾驶;

通过运行在第二虚拟机中的座舱域程序,根据所述视频并行数据及预存于所述共享内存片区的视频参数数据,生成合成视频流并在显示屏展示。

本系统的实现方式与上述步骤101实现过程类似,此处不再赘述。

综上,在本申请实施例中,通过在电子控制单元上建立了分别运行有自动驾驶程序的第一虚拟机与座舱域程序的第二虚拟机,并将外部获取的视频并行数据存储于共享内存中,两部虚拟机分别通过设置于电子控制单元的虚拟总线,调用视频并行数据,抛弃了现有技术中将自动驾驶程序与座舱程序运行于实体处理器,再通过实体总线相互数据通信的方式。由此,基于本申请实施例的方法,消除了硬线连接、使得设备开发软件化并提高了整体的传输效率,解决了智能驾舱设计架构中由于传统双电子控制单元之间的多数据总线需求而造成的多硬线连接、设备复杂度高、数据传输效率低的问题。

如图8所示为本申请实施例的一种舱驾融合的数据传输装置30,其特征在于,包括:

视频解串模块301,用于获取视频并行数据,并将视频并行数据存储到共享内存片区;

数据服务订阅模块302,用于通过运行在虚拟总线程序中的数据提供服务,将视频并行数据自所述共享内存片区并行调用分发至第一虚拟机及第二虚拟机中;

自动驾驶模块303,用于通过运行在第一虚拟机中的自动驾驶程序,根据所述视频并行数据执行自动驾驶;

视频串流模块304,用于通过运行在第二虚拟机中的座舱域程序,根据所述视频并行数据及预存于所述共享内存片区的视频参数数据,生成并输出合成视频流。

可选地,响应于所述第一虚拟机及所述第二虚拟机的内核占用请求,通过资源管理虚拟机获取预设的索引表,以及当前实体内核的占用情况;所述索引表记录了实体内核与虚拟内核之间的对应关系;

所述数据传输装置还包括:

第一资源管理模块,用于根据当前实体内核的占用情况,确定当前为空闲的目标实体内核;

第二资源管理模块,用于通过资源管理虚拟机,按照记录了所述实体内核与所述虚拟内核之间的对应关系的索引表,确定与所述目标实体内核对应的目标虚拟内核,并将所述目标虚拟内核分配给所述第一虚拟机及所述第二虚拟机。

可选地,所述视频并行数据包含多个外部数据流,每个所述外部数据流由对应的一个环视摄像头生成,

所述获取视频解串模块301具体包括:

第一视频解串子模块,用于获取多路外部视频流,以及通过自动驾驶程序对外部视频流进行标定数据的提取;

第二视频解串子模块,用于通过所述自动驾驶程序利用标定数据,对所述多路外部视频流进行拼接,获得视频并行数据。

可选地,所述视频串流模块304还包括:

第一视频串流子模块,用于通过所述运行在第二虚拟机中的座舱域程序,将所述视频并行数据逐帧缩放,得到缩放视频;

第二视频串流子模块,用于通过所述座舱域程序,使用所述视频参数数据对缩放视频进行简化处理,获得至少一种视频素材;所述视频素材包括:二维视图、三维视图、车模视图、辅助线视图、雷达视图中的一种或多种;

第三视频串流子模块,用于响应于展示指令,根据至少一种视频素材生成所述合成视频流。

可选地,所述视频参数数据包括摄像头标定参数、初始化结果、占用状态、故障状态;所述视频串流模块304还包括:

第四视频串流子模块,用于所述通过运行在第二虚拟机中的座舱域程序,根据所述视频并行数据及预存于所述共享内存片区的视频参数数据,生成并输出合成视频流;

第五视频串流子模块,用于根据初始化结果、占用状态、故障状态,进行车辆当前状态的判断,获得判断结果;

第六视频串流子模块,用于在判断结果为异常的情况下,进行故障告警;

第七视频串流子模块,用于在判断结果为正常的情况下,通过所述座舱域程序,根据所述视频并行数据及预存于所述共享内存片区的视频参数数据,生成合成视频流并输出。

可选地,所述自动驾驶模块303包括:

第一自动驾驶子模块,用于根据所述视频并行数据,检测当前车辆所处环境中的驾驶对象;

第二自动驾驶子模块,用于根据所述驾驶对象,初始化驾驶路径;

第三自动驾驶子模块,用于根据所述视频并行数据,确定处于所述初始路径中的障碍物;

第四自动驾驶子模块,用于当根据所述障碍物确定车辆无需绕行时,根据驾驶路径执行自动驾驶;

第五自动驾驶子模块,用于当根据所述障碍物确定车辆需要绕行时,根据所述视频并行数据调整驾驶路径,根据调整后的驾驶路径自动驾驶;

第六自动驾驶子模块,用于当根据所述障碍物确定车辆无法绕行时,执行刹车或减速停车指令。

可选地,所述第二虚拟机为运行在第一虚拟机中的嵌入式虚拟机。

综上,在本申请实施例中,通过在电子控制单元上建立了分别运行有自动驾驶程序的第一虚拟机与座舱域程序的第二虚拟机,并将外部获取的视频并行数据存储于共享内存中,两部虚拟机分别通过设置于电子控制单元的虚拟总线,调用视频并行数据,抛弃了现有技术中将自动驾驶程序与座舱程序运行于实体处理器,再通过实体总线相互数据通信的方式。由此,基于本申请实施例的方法,消除了硬线连接、使得设备开发软件化并提高了整体的传输效率,解决了智能驾舱设计架构中由于传统双电子控制单元之间的多数据总线需求而造成的多硬线连接、设备复杂度高、数据传输效率低的问题。

参照图9,电子设备500可以包括以下一个或多个组件:处理组件502,存储器505,电源组件506,多媒体组件508,音频组件510,输入/输出(I/O)接口512,传感器组件514,以及通信组件516。

处理组件502通常控制电子设备500的整体操作,诸如与显示,电话呼叫,数据通信,相机操作和记录操作相关联的操作。处理组件502可以包括一个或多个处理器520来执行指令,以完成上述的方法的全部或部分步骤。此外,处理组件502可以包括一个或多个模块,便于处理组件502和其他组件之间的交互。例如,处理组件502可以包括多媒体模块,以方便多媒体组件508和处理组件502之间的交互。

存储器504用于存储各种类型的数据以支持在电子设备500的操作。这些数据的示例包括用于在电子设备500上操作的任何应用程序或方法的指令,联系人数据,电话簿数据,消息,图片,多媒体等。存储器504可以由任何类型的易失性或非易失性存储设备或者它们的组合实现,如静态随机存取存储器(SRAM),电可擦除可编程只读存储器(EEPROM),可擦除可编程只读存储器(EPROM),可编程只读存储器(PROM),只读存储器(ROM),磁存储器,快闪存储器,磁盘或光盘。

电源组件506为电子设备500的各种组件提供电力。电源组件506可以包括电源管理系统,一个或多个电源,及其他与为电子设备500生成、管理和分配电力相关联的组件。

多媒体组件508包括在电子设备500和用户之间的提供一个输出接口的界面。在一些实施例中,界面可以包括液晶显示器(LCD)和触摸面板(TP)。如果界面包括触摸面板,界面可以被实现为触摸屏,以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的分界,而且还检测与触摸或滑动操作相关的持续时间和压力。在一些实施例中,多媒体组件508包括一个前置摄像头和/或后置摄像头。当电子设备500处于操作模式,如拍摄模式或多媒体模式时,前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件510用于输出和/或输入音频信号。例如,音频组件510包括一个麦克风(MIC),当电子设备500处于操作模式,如呼叫模式、记录模式和语音识别模式时,麦克风用于接收外部音频信号。所接收的音频信号可以被进一步存储在存储器504或经由通信组件516发送。在一些实施例中,音频组件510还包括一个扬声器,用于输出音频信号。

输入/输出I/O接口512为处理组件502和外围接口模块之间提供接口,上述外围接口模块可以是键盘,点击轮,按钮等。这些按钮可包括但不限于:主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件514包括一个或多个传感器,用于为电子设备500提供各个方面的状态评估。例如,传感器组件515可以检测到电子设备500的打开/关闭状态,组件的相对定位,例如组件为电子设备500的显示器和小键盘,传感器组件514还可以检测电子设备500或电子设备500一个组件的位置改变,用户与电子设备500接触的存在或不存在,电子设备500方位或加速/减速和电子设备500的温度变化。传感器组件514可以包括接近传感器,被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件515还可以包括光传感器,如CMOS或CCD图像传感器,用于在成像应用中使用。在一些实施例中,该传感器组件514还可以包括加速度传感器,陀螺仪传感器,磁传感器,压力传感器或温度传感器。

通信组件516用于便于电子设备500和其他设备之间有线或无线方式的通信。电子设备500可以接入基于通信标准的无线网络,如WiFi,运营商网络(如2G、3G、4G或5G),或它们的组合。在一个示例性实施例中,通信组件516经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中,通信组件516还包括近场通信(NFC)模块,以促进短程通信。例如,在NFC模块可基于射频识别(RFID)技术,红外数据协会(IrDA)技术,超宽带(UWB)技术,蓝牙(BT)技术和其他技术来实现。

在示例性实施例中,电子设备500可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现,用于实现本申请实施例提供的一种显示控制方法。

在示例性实施例中,还提供了一种包括指令的非临时性计算机可读存储介质,例如包括指令的存储器504,上述指令可由电子设备500的处理器520执行以完成上述方法。例如,非临时性存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

图10是本发明另一个实施例的电子设备600的框图。例如,电子设备600可以被提供为一服务器。参照图10,电子设备600包括处理组件622,其进一步包括一个或多个处理器,以及由存储器632所代表的存储器资源,用于存储可由处理组件622的执行的指令,例如应用程序。存储器632中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外,处理组件622被配置为执行指令,以执行本申请实施例提供的一种显示控制方法。

电子设备600还可以包括一个电源组件626被配置为执行电子设备600的电源管理,一个有线或无线网络接口650被配置为将电子设备600连接到网络,和一个输入/输出(I/O)接口658。电子设备600可以操作基于存储在存储器632的操作系统,例如WindowsServerTM,Mac OS XTM,UnixTM,LinuxTM,FreeBSDTM或类似。

本领域技术人员在考虑说明书及实践这里公开的申请后,将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本申请的真正范围和精神由下面的权利要求指出。

应当理解的是,本申请并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

相关技术
  • 一种驾考装置及驾考方法、系统、设备、计算机介质
  • 数据传输方法、装置、系统及设备、介质
  • 基于人脸识别的酒驾检测方法、装置、设备和存储介质
  • 基于双向网闸的数据传输方法、装置、设备及介质
  • 数据传输方法、装置、电子设备及存储介质
  • 舱驾场景融合方法、装置、存储介质及电子装置
  • 人机共驾的意图融合控制方法、装置、设备及存储介质
技术分类

06120116514665