CN109756546B - 智能网联汽车云控操作系统 - Google Patents

Abstract

本申请公开了一种智能网联汽车云控操作系统，该操作系统中设置有区域通信接口、应用接口、外设接口、总线接口和守护进程。通过以不同的业务逻辑调用上述接口，实现了智能网联汽车内部通信、智能网联汽车与路侧设备、云端平台或智能网联系统中其它网联汽车之间的外部通信，完成智能网联系统中各节点间的资源信息共享和业务实现，进而通过各节点的协同运行实现特定的场景任务。

Description

智能网联汽车云控操作系统

技术领域

本申请涉及自动驾驶技术领域，尤其涉及一种智能网联汽车云控操作系统。

背景技术

随着经济发展汽车数量飞速增长，导致交通阻塞、能源消耗以及大气污染等问题日益严重，这使得即便道路设施十分发达的国家也不得不从以往只靠供给来满足需求的思维模式转向采取供、需两方面共同管理的技术和方法来改善日益尖锐的交通问题。在此过程中，“智能网联交通系统”的概念便逐步形成，而智能网联和自动驾驶技术正是实现智能交通的一个重要技术手段。

智能网联的快速发展要求车辆的网络化和智能化，要求现有技术中的车辆能够实现车与车、车与人、车与路侧设备、车与云端平台的信息交互。而且能够在多种不同形态的终端中实现业务融合。

有鉴于此，现有技术中需要提出一种操作系统来合理且有效地组织管理智能网联汽车的硬件和软件资源，最大限度地发挥它们的作用，充分实现智能网联汽车的各种功能。

发明内容

本说明书实施例提供一种智能网联汽车云控操作系统，以合理而有效地组织管理硬件和软件资源，从而实现智能网联汽车的智能化。

本说明书实施例提供的一种智能网联汽车云控操作系统，具体包括：

区域通信接口，用于与智能网联系统中其余智能网联汽车或路侧设备通信；其中，所述智能网联系统包括至少两个智能网联汽车和路侧设备；

应用接口，用于向安装于所述操作系统的车载应用传输数据，以使所述车载应用控制所述智能网联汽车。

本说明书实施例采用上述至少一个技术方案能够达到以下有益效果：

通过以不同的业务逻辑调用上述接口，本申请可以实现智能网联汽车内部通信及智能网联汽车与路侧设备、云端平台或智能网联系统中其余智能网联汽车之间的通信，及智能网联系统中各节点间的资源信息共享和业务实现，进而通过各节点的协同运行实现特定的场景任务。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本说明书实施例提供的智能网联系统所基于的架构示意图；

图2a为本说明书实施例提供的用于智能网联汽车云控操作系统的结构示意图；

图2b为本说明书实施例提供的用于智能网联汽车云控操作系统的结构示意图；

图3是本说明书实施例提供的基于智能网联汽车云控操作系统的车辆控制方法流程图；

图4是本说明书实施例提供的用于智能网联汽车云控操作系统的应用场景示意图。

具体实施方式

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

本实施例中所述的智能网联系统由至少一个云端平台、多个智能网联汽车、多个路侧设备构成；其中，云端平台、智能网联汽车和路侧设备之间可以相互建立连接并进行通信。

在本说明书的一个或多个实施例中，所述的智能网联系统可采用如图1所示的架构。在所述的架构中，所述智能网联汽车云控操作系统通过远程通信接口与云端平台(以云端服务器的形式)进行通信，通过区域通信接口同路侧设备进行通信。

所述的云端平台包括诸如安全子系统、运维子系统、云计算子系统、数据融合子系统、业务应用子系统等不用功能子系统以支持基础平台实现数据融合、存储、用户认证和授权、数据审计和防护等服务功能，并通过诸如消息队列、高速缓存、负载均衡等云计算能力提供监控预警、交通管控、编队行驶等对汽车网联汽车的服务，以实现诸如车辆共享、保费计算、智能保养等功能。

所述的智能网联汽车可以由云端平台提供唯一标识以进行身份认证(例如，由平台作为签发机构颁发的ITU-TX.509证书，VIN(Vehicle Identification Number，车辆识别码)，具体的数据采集方式、数据通信方式、通信协议等在当前技术中已经较为成熟，此处不再赘述。

所述路侧设备可以是V2X技术中所定义的路侧单元，或具有区域广播通信能力和计算能力的其他设备。具体的，路侧设备可以设置于车辆行驶过程中需经过的区域中，以保证路侧设备和智能网联汽车之间的可靠低时延通信。

本说明书实施例中提供用于智能网联汽车云控操作系统，如图2a所示，具体包括以下部分：

区域通信接口210，用于与智能网联系统中其余智能网联汽车或路侧设备通信；其中，所述智能网联系统包括至少两个智能网联汽车和路侧设备；

应用程序接口220，用于向安装于所述操作系统的车载应用传输数据，以使所述车载应用控制所述智能网联汽车。

具体的，所述区域通信接口可以是通过DSRC(Dedicated Short RangeCommunications，专用短程通信技术)、LTE-V(LTE-Vehicle to Everything)、5G等方式，在有限区域内与智能网联汽车、路侧设备、行人等进行通信的接口，可以理解为V2X(Vehicleto Everything)协议栈。

可以选择的，该区域通信接口可以屏蔽区域通信设备的差异性，隐藏通信过程细节的复杂性，进而实现支持任意类别的通信设备，简化了应用程序的开发流程。

在上述实施例的基础上，所述智能网联系统中还包括云端平台；对应的，所述智能网联汽车云控操作系统还包括：远程通信接口230，用于所述与云端平台通信。

具体而言，所述远程通信接口可以通过蜂窝网络实现通信。

可选的，与远程通信接口对应的功能模块可以用来封装与云端平台相关的应用，不仅简化智能网联汽车与云端平台交互过程中繁琐操作，同时还使交互过程更加可靠和安全。

在上述实施例的基础上，所述智能网联汽车云控操作系统还包括：外设接口240，用于与所述智能网联汽车的外接设备通信，其中，所述外界设备可以是雷达、摄像头或定位设备，通过所述外设接口240可以屏蔽外界设备的硬件差异。

进一步的，所述外设接口240在操作系统的内核层中提供外接设备的驱动程序，驱动程序具体包括雷达驱动程序、定位设备驱动程序、摄像头驱动程序、温度传感器驱动程序、湿度传感器驱动程序和/或无线通信设备驱动程序。其中，所述雷达驱动程序包括激光雷达驱动程序和毫米波雷达驱动程序。

更进一步的，所述外设接口可以用于接收和获取外接设备的传输数据。

在上述实施例的基础上，所述操作系统还包括：总线接口250，用于采集所述智能网联汽车的内部数据和/或传输车辆控制数据。具体的，所述总线接口是车辆总线的接口，可以用于通过标准的接口简化应用程序开发，为应用程序屏蔽不同车型的数据格式差异，进而屏蔽车辆控制的过程细节。

在上述实施例的基础上，所述操作系统还包括：

守护进程260，运行于操作系统的后台，用于更新操作系统、持续采集数据和/或执行业务逻辑。

具体的，守护进程260是在操作系统后台持续运行的程序，可以与所述区域通信接口210、应用程序接口220、远程通信接口230、外设接口240、总线接口250相互协作，在不同场景需求下实现多种功能。

可选的，守护进程可以作为一种接口功能的实现手段，并可以将部分耗时较长的接口调用由同步方式变为事件驱动的异步方式。

在上述实施例的基础上，所述操作系统的软件机制中还包括安全机制，用于安全防护、安全管控和系统自身鲁棒性安全保障。所述系统鲁棒性安全保障通过系统监控、异常发现、异常处理，及时发现、恢复系统运行中的错误；对异常进程占用的资源进行有效回收；防止系统异常操作导致的系统崩溃；并通过与安全芯片、安全Loader结合，实现系统安全升级更新，并根据操作系统软件架构层次的功能和编程语言特性加入不同的安全模块，这些安全模块各司其职，分管所处软件层的安全管控，同时它们又是一个有机的整体，互相通信，协同工作，实现操作系统整体的安全管控。

可以选择的，智能网联汽车云控操作系统的结构还可以如图2b中的示意图设置。

具体的，如图2b所示，所述守护进程260可以与区域通信接口210、远程通信接口230、外设接口240和总线接口250中的任意一个接口相连，作为与应用接口与其余接口的连接，进而使车载应用280可以通过应用接口220和守护进程260调用其余接口，并执行对应的业务逻辑。

可选的，车载应用260还可以直接调用智能网联汽车云控操作系统中的区域通信接口210、远程通信接口230、外设接口240和总线接口250，并完成对应的业务逻辑。其中，所述车载应用可以实现安全预警、防碰撞、自动驾驶等功能。

在一些实施例中，将提供一种应用场景来描述所述操作系统的功能。图3是本说明书实施例提供的基于智能网联汽车云控操作系统的车辆控制方法流程图。

如图3所示，该车辆控制方法包括：

步骤S300、当设置于第一车辆的车载雷达或摄像头检测到障碍物时，通过设置于第一车辆的外设接口发送障碍物信息至第一车辆的守护进程；

步骤S302、第一车辆的守护进程通过第一车辆的远程通信接口发送障碍物信息至云端平台；

步骤S304、云端平台根据障碍物信息作出判断，得到第一判断结果，并将第一判断结果发送至第二车辆和第三车辆；其中，第一判断结果包括第二车辆的变道避障指令和第三车辆的减速让行指令；

步骤S306、云端平台发送避让指令至第二车辆，同时发送减速让行指令至第三车辆；

步骤S308、第二车辆的守护进程通过第二车辆的远程通信接口接收变道避障指令，并通过第二车辆的应用接口将变道避障指令发送至第二车辆的自动驾驶模块；

步骤S310、第二车辆的自动驾驶模块根据变道避障指令，并通过设置于第二车辆的总线接口控制第二车辆的车辆电子控制单元以实现变道；同时，第二车辆的自动驾驶模块通过第二车辆的区域通信模块将变道避障事件通知发送至第三车辆；

步骤S312、第三车辆的守护进程通过第三辆车的区域通信接口接收变道避障事件通知，并通过第三辆车的远程通信接口接收减速让行指令；

步骤S314、第三车辆的守护进程根据所述减速让行指令和变道避障事件通知作出判断，得到第二判断结果，其中，所述第二判断结果包括第三车辆的减速让行执行指令；

步骤S316、通过第三车辆的应用接口将减速让行执行指令发送至第三车辆的自动驾驶模块，第三车辆的自动驾驶模块通过第三车辆的总线接口控制第三车辆的车辆电子控制单元，以进行减速避让。

具体的，如图4所述，当A车遇到障碍物时，首先会利用设置于A车的守护进程，通过外设接口收到雷达发出的数据，以表示发现相邻道路前方发现障碍物，同时利用守护进程并通过远程通信接口将障碍物信息发往云端平台；云端平台收到相关信息后进行判断B车是否应该避让，进而通过设置于B车的操作系统中的远程通信接口将判断结果发送至B车；B车接收到判断结果后，会通过区域通信接口将判断结果的以消息广播的方式传输出去，并通过总线接口控制B车的ECU(Electronic Control Unit，电子控制单元)，以使B车进行变道；C车通过区域通信接口接收到消息广播后，也会通过应用接口将该消息通知给自动驾驶模块，自动驾驶模块控制C车的ECU实现制动以避让B车。可选的，云平台也可以通过远程通信接口将制动避让指令发送给C车，进而通过应用接口传递给C车的自动驾驶模块，再通过总线接口控制C车ECU实现制动避让。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备和介质类实施例而言，这里就不再一一赘述。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤或模块可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信编号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定事务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行事务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利范围之中。

Claims (9)

1.一种智能网联汽车云控操作系统，其特征在于，包括：

区域通信接口，用于与智能网联系统中其余智能网联汽车或路侧设备通信；其中，所述智能网联系统包括至少两个智能网联汽车和路侧设备；

应用接口，用于向安装于所述操作系统的车载应用传输数据，以使所述车载应用根据接收的所述数据控制所述智能网联汽车，其中，所述车载应用控制所述智能网联汽车包括自动驾驶，所述数据包括智能网联汽车内部数据和车辆控制数据。

2.根据权利要求1所述的智能网联汽车云控操作系统，其特征在于，所述智能网联系统中还包括云端平台；

对应的，所述智能网联汽车云控操作系统还包括：

远程通信接口，用于与所述云端平台通信。

3.根据权利要求1所述的智能网联汽车云控操作系统，其特征在于，还包括：

外设接口，用于与所述智能网联汽车的外接设备通信。

4.根据权利要求1所述的智能网联汽车云控操作系统，其特征在于，还包括：

总线接口，用于采集所述智能网联汽车的内部数据和/或传输车辆控制数据。

5.根据权利要求1所述的智能网联汽车云控操作系统，其特征在于，还包括：

守护进程，用于更新操作系统、持续采集数据和/或执行业务逻辑。

6.根据权利要求1所述的智能网联汽车云控操作系统，其特征在于，还包括：

内核层，包括实现进程管理、内存管理、文件系统、网络协议和/或硬件驱动的功能组件。

7.根据权利要求6所述的智能网联汽车云控操作系统，其特征在于：

内核层所提供的驱动程序包括雷达驱动程序、定位设备驱动程序、摄像头驱动程序、温度传感器驱动程序、湿度传感器驱动程序和/或无线通信设备驱动程序。

8.根据权利要求1所述的智能网联汽车云控操作系统，其特征在于：

所述操作系统的软件机制中还包括安全机制，用于安全防护、安全管控和系统自身鲁棒性安全保障。

9.一种基于如权利要求1-8任一所述的智能网联汽车云控操作系统的车辆控制方法，其特征在于，包括：

当设置于第一车辆的车载雷达或摄像头检测到障碍物时，通过设置于第一车辆的外设接口发送障碍物信息至第一车辆的守护进程；

第一车辆的守护进程通过第一车辆的远程通信接口发送障碍物信息至云端平台；

云端平台根据障碍物信息作出判断，得到第一判断结果，并将第一判断结果发送至第二车辆和第三车辆；其中，第一判断结果包括第二车辆的变道避障指令和第三车辆的减速让行指令；

云端平台发送避让指令至第二车辆，同时发送减速让行指令至第三车辆；

第二车辆的守护进程通过第二车辆的远程通信接口接收变道避障指令，并通过第二车辆的应用接口将变道避障指令发送至第二车辆的自动驾驶模块；

第二车辆的自动驾驶模块根据变道避障指令，并通过设置于第二车辆的总线接口控制第二车辆的车辆电子控制单元以实现变道；同时，第二车辆的自动驾驶模块通过第二车辆的区域通信模块将变道避障事件通知发送至第三车辆；

第三车辆的守护进程通过第三辆车的区域通信接口接收变道避障事件通知，并通过第三辆车的远程通信接口接收减速让行指令；

第三车辆的守护进程根据所述减速让行指令和变道避障事件通知作出判断，得到第二判断结果，其中，所述第二判断结果包括第三车辆的减速让行执行指令；

通过第三车辆的应用接口将减速让行执行指令发送至第三车辆的自动驾驶模块，第三车辆的自动驾驶模块通过第三车辆的总线接口控制第三车辆的车辆电子控制单元，以进行减速避让。

Images