CN117774847A - 车辆控制架构和车辆 - Google Patents

Abstract

本申请提供了一种车辆控制架构和车辆，其中车辆控制架构可以包括：设置有多个槽位的主板，主板通过槽位插接中央控制器和功能板卡，功能板卡用于控制车辆执行第一类功能，第一类功能是根据功能对算力的需求和功能迭代的速度进行划分的；功能板卡为多个，每一个功能板卡执行的第一类功能彼此不同；中央控制器用于将获取到的参数转发至功能板卡；参数是功能板卡执行第一类功能所需的；中央控制器还用于利用预先集成的控制指令集，控制车辆执行第二类功能；第二类功能为车辆所执行的除第一类功能以外的功能。

Description

车辆控制架构和车辆

技术领域

本申请涉及车辆控制技术领域，尤其涉及一种车辆控制架构和车辆。

背景技术

随着车辆技术的持续升级，车辆中的电子控制系统复杂度迅速增加，对协同控制和信息交互量的需求也大幅提升。针对目前车辆中繁多的功能，通常是采用分立的多个电子控制单元来实现，例如一个独立的电子控制单元用于实现一项或多项功能，这样就会导致车辆整体的电气架构变得非常复杂、且布线复杂度提高，从而造成安全隐患。此外，电子控制单元数量的蹭到也会导致整车成本居高不下。

发明内容

本申请实施例提供一种车辆控制架构和车辆。

第一方面，本申请实施例提供了一种车辆控制架构，车辆控制架构可以包括：

设置有多个槽位的主板，主板通过槽位插接中央控制器和功能板卡，功能板卡用于控制车辆执行第一类功能，第一类功能是根据功能对算力的需求和功能迭代的速度进行划分的；功能板卡为多个，每一个功能板卡执行的第一类功能彼此不同；

中央控制器用于将获取到的参数转发至功能板卡；参数是功能板卡执行第一类功能所需的；

中央控制器还用于利用预先集成的控制指令集，控制车辆执行第二类功能；第二类功能为车辆所执行的除第一类功能以外的功能。

第二方面，本申请实施例提供了一种车辆，该车辆包括车辆本体以及如第一方面所涉及的应用于车辆的车辆控制架构，应用于车辆的车辆控制架构设置在车辆本体中。

与现有技术相比，本申请具有如下优点：

依据本申请实施例，通过集成中控和域控功能的中央控制器，以及功能板卡在主板的可插接设置，可以简化车辆控制架构从而降低整车成本，此外，由于控制架构的简化，可以大量节约线束，降低安全隐患。此外，对于可插接设置的功能板卡，在功能板卡更新迭代的情况下，可以快速实现对更新版本的接入，提高了车辆的竞争力。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，可依照说明书的内容予以实施，并且为了让本申请的上述和其他目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

在附图中，除非另外规定，否则贯穿多个附图相同的附图标记表示相同或相似的部件或元素。这些附图不一定是按照比例绘制的。应该理解，这些附图仅描绘了根据本申请的一些实施方式，而不应将其视为是对本申请范围的限制。

图1为本申请提供的车辆控制架构的硬件示意图；

图2为本申请一实施例的通信管理流程示意图；

图3是本申请提供的中央控制器的示意图。

具体实施方式

在下文中，仅简单地描述了某些示例性实施例。正如本领域技术人员可认识到的那样，在不脱离本申请的构思或范围的情况下，可通过各种不同方式修改所描述的实施例。因此，附图和描述被认为本质上是示例性的，而非限制性的。

为便于理解本申请实施例的技术方案，以下对本申请实施例的相关技术进行说明。以下相关技术作为可选方案与本申请实施例的技术方案可以进行任意结合，其均属于本申请实施例的保护范围。

本申请实施例提供了一种车辆控制架构，如图1所示为本申请一实施例的车辆控制架构的示意图，车辆控制架构可以包括：

设置有多个槽位的主板，主板通过槽位插接中央控制器和功能板卡，功能板卡用于控制车辆执行第一类功能，第一类功能是根据功能对算力的需求和功能迭代的速度进行划分的；功能板卡为多个，每一个功能板卡执行的第一类功能彼此不同；

中央控制器用于将获取到的参数转发至功能板卡；参数是功能板卡执行第一类功能所需的；

中央控制器还用于利用预先集成的控制指令集，控制车辆执行第二类功能；第二类功能为车辆所执行的除第一类功能以外的功能。

目前在新能源汽车中，会存在多个控制域计算平台。例如，娱乐域计算平台(IDCM)负责车内娱乐和信息交互。智能驾驶域计算平台(ADCM)负责车辆的智能驾驶功能。动力和底盘域计算平台(VDCM)负责管理动力系统和底盘控制。车身域计算平台(BDCM)负责车身相关功能的控制。中央网关(CGW)负责各个计算平台之间的数据交换和协调。而T-Box通信计算平台负责车辆与外部网络的通信功能，即车联网通信功能。这种车辆控制架构的优势在于它的模块化设计和高度互联互通，不同计算平台之间可以通过数据共享和协同工作，实现全车系统的智能化功能。但另一方面，多个控制域计算平台均对应有各自的硬件模块，由此会导致车辆整体的电气架构变得非常复杂、且布线复杂度提高，从而造成安全隐患以及成本的增加。

因此，本申请考虑将多个控制域计算平台进行融合，从而完成对车辆控制架构的简化。在本申请中，首先将所有控制域计算平台执行的功能进行类别划分。划分方式是根据功能对算力的需求和功能迭代的速度进行。示例性地，智能驾驶域计算平台对应的智能驾驶功能能够使车辆具备多传感器融合、定位、路径规划、决策控制、图像识别、高速通讯、数据处理的能力。智能驾驶域计算平台通常需要外接多个摄像头、毫米波雷达、激光雷达等等车载传感器来感知周围环境，通过传感器数据处理及多传感器信息融合以及适当的工作模型制定相应的策略，进行驾驶决策与规划。智能驾驶域计算平台的输入为各项传感器的数据，所进行的算法处理涵盖了感知、决策、控制三个层面，最终将输出传送至执行机构，进行车辆的横纵向控制。智能驾驶域计算平台对应的智能驾驶功能需要处理大量数据，因此对算力要求较高。可以划分成第一类。

娱乐域计算平台负责执行车内娱乐和信息交互等功能。娱乐功能可以包括副驾驶和后排的屏幕娱乐、人机交互等。信息交互可以包括信息在不同模块或芯片之间的传输等。车内娱乐和信息交互等功能升级迭代速率较快，可以划分成第一类。

T-Box通信计算平台负责的车联网通信，主要指车辆与外部的通信。由于车联网通信升级迭代速率较快，也可以划分成第一类。

此外，除了智能驾驶功能、车内娱乐和信息交互等功能以及车联网功能以外的车辆所执行的其他功能，可以划分成第二类功能。示例性地，第二类功能可以包括车身域计算平台负责的车身相关功能、电池管理的相关功能等。

基于此，在确定出第一类功能和第二类功能后，将第一类功能的控制管理硬件化，将第二类功能的控制管理软件集成化。即，配置与多个第一类功能对应的功能板卡。每一个功能板卡对应一个第一功能。例如，执行智能驾驶功能的板卡对应智能驾驶功能的控制管理，执行影音娱乐功能的板卡对应车内娱乐和信息交互等功能的控制管理，执行车联网功能的板卡对应车联网通信功能的控制管理。每个功能板卡以插接的方式安装于设置有多个槽位的主板。示例性地，插接方式可以包括通过PCIe总线接口插接，通过M.2接口插接等。此外，还配置有插接在主板槽位的中央控制器，中央控制器可以集成中控和域控的功能，一方面可以将获取到的功能板卡执行第一类功能所需的参数转发至功能板卡。例如，在图1所示示例中，中央控制器通过与前区域控制器的通信，获取雷达采集到的数据。雷达采集到的数据可以对应执行智能驾驶功能所需的参数，中央控制器将雷达采集到的数据发送至执行智能驾驶功能的板卡，以便执行智能驾驶功能的板卡执行自动驾驶控制管理。在图1中，仅对前区域控制器所控制的部分被控设备进行示例性说明，实际场景中每个区域控制器可以与多个被控设备相对应。例如，左侧控制器可以与左侧转向灯、左侧车门、车窗、车锁以及布设在车身左侧的图像采集设备等相对应。其他对应关系不再穷举。

另一方面，通过软件集成的方式预先集成控制指令集，从而可以直接对车辆执行第二类功能进行控制管理。例如，结合图1所示，根据预先集成的车身域控制指令，实现对于车内空调温度和送风量的控制。即，中央控制器向通过与前区域控制器的通信，输出空调温度和送风量的控制指令，由前区域控制器将控制指令作用于空调。所谓第二类功能可以对应更新迭代较慢或者对算力要求较低的功能。对算力要求较低意味着可以节省单独的控制域，从而通过集成控制的方式降低成本。更新迭代较慢的功能，由于不需要频繁的更新，其控制技术相对成熟，由此可以也可以通过集成控制的方式降低成本。

通过集成中控和域控功能的中央控制器，以及功能板卡在主板的可插接设置，可以简化车辆控制架构从而降低整车成本，此外，由于控制架构的简化，可以大量节约线束，降低安全隐患。此外，对于可插接设置的功能板卡，在功能板卡更新迭代的情况下，可以快速实现对更新版本的接入，提高了车辆的竞争力。

在一种实施方式中，中央控制器将获取到的参数转发至功能板卡，具体包括：

确定待获取参数的属性；属性是根据待获取参数的数据量和实时性要求确定的；

选择与属性匹配的传输协议；

利用选择出的传输协议获取参数。

以功能板卡为执行智能驾驶功能的板卡为示例进行说明。对于执行智能驾驶功能的板卡，其执行的第一类功能便是智能驾驶控制管理。根据智能驾驶算法的不同，执行智能驾驶控制功能所需的参数可以包括视觉数据对应的参数以及雷达数据对应的参数等；此外，执行智能驾驶控制功能所需的参数还可以包括例如限速数据对应的参数、信号灯数据对应的参数等。

这些参数的数据量或者实时性要求是不同的。示例性地，对于限速数据对应的参数，其对实时性要求会低于视觉数据对应的参数以及雷达数据对应的参数。但同时，视觉数据对应的参数的数据量会远远大于限速数据、信号灯数据等。由此，根据这些特性，对于参数的属性为实时性高但数据量低的参数，可以选择CAN总线传输协议，保障数据传输的效率。对于参数的属性为实时性较高但数据量大的参数，可以选择以太网传输协议，同时保障数据传输的速度和完整性。

由此，对于不同参数，可以利用不同的传输协议进行传输。一来避免数据拥挤，二来保障不同的数据都可以准确发送。

在一种实施方式中，中央控制器和功能板卡共用主板的微控制单元，中央控制器利用微控制单元执行对功能板卡的供电管理和通信管理。

在传统的车辆域控制中，每一个域计算平台都会配置一个算力较强的中央处理器(CPU，Central Processing Unit)或微处理器(MPU，Microprocessor Unit)执行计算动作。同时还会配置一个微控制单元(MCU，Microcontroller Unit)执行域计算平台自身的电源管理，以及与其他域计算平台之间的通信等。由此一来，域计算平台越多，无形中就会造成更高的造车成本。基于此，在本申请中，功能板卡与中央控制器均插接于主板，从而可以共用主板的微控制单元。即，中央控制器利用被共用的微控制单元同时处理每个功能板卡的供电和通信管理。

由此，一方面最大程度发挥微控制单元的能效。另一方面，整个车辆的控制架构只需一个微控制单元，由此可以极大程度的节省造车成本。

在一种实施方式中，功能板卡包括执行智能驾驶功能的板卡、执行影音娱乐功能的板卡和执行车联网功能的板卡中的至少一种。

前已述及，功能板卡是用于执行第一类功能的，而第一类功能的划分方式是根据功能对算力的需求和功能迭代的速度进行划分的。也就是说，对于迭代的速度较快的功能而言，通过插接的方式可以实现功能的快速迭代更新。例如，执行车联网功能的板卡可以是适配第五代移动通信标准的板卡，而通信标准的升级迭代已飞速发展。例如，目前已有大量的第六代移动通信标准技术相关技术，由此，当出现适配第六代移动通信标准的板卡时，也可以通过插接的方式及时完成新技术的升级和兼容。

此外，对于算力的需求较大的功能通常是智能驾驶功能，通常存在多个产商进行研发等。由此，可以通过个性化选择，实现智能驾驶功能的适配。选择最为适合的智能驾驶功能作为车辆使用。

在一种实施方式中，供电管理具体可以包括：

根据车辆的状态，确定对被控部件的控制指令；

选择包含被控部件的编码表；编码表是预先构建的，存储有被控部件以及被控部件的编码；

利用编码表，生成与控制指令对应的配电报文；配电报文用于供电管理。

车辆的状态可以包括电量状态，也可以包括行驶状态等。电量状态可以是剩余电量、行驶至目的地的可用电量等。行驶状态可以是是否在夜间行驶、是否在雨雪天气行驶、是否要转向行驶等。根据不同的行驶状态，中央控制器可以确定对被控部件的控制指令。举例而言，如果是夜间行驶，那么就需要生成车灯开启控制指令。如果是剩余电量有限，剩余电量有可能无法到达目的地等，那么可以生成对空调或者车内影音娱乐等耗电量大的部件的关闭控制指令。

对于车内的被控部件，可以对其进行分组。分组可以是依照被控部件位于车身的位置，也可以是依照被控部件的耗电量，还可以是依照被控部件不同的属性等。例如下表1所示为将被控部件依照属性进行分组，如依照部件类别划分，可以包括外部灯光和电动车门。进一步的，再依照模块划分，外部灯光又可以包含前大灯和尾部灯光。电动车门又可以包含左前车门、右前车门、左后车门、右后车门等。对于不同的被控部件，可以预先对其进行编号并存储编码表。示例性说明，表1中前大灯的编号为S01-1、尾部灯光的编号为S02-2。最终，可以利用编号生成配电报文，从里利用配电报文对应控制指令。示例性地，可以以“1”对应开启控制指令，以“0”对应关闭控制指令。表1中的配电报文“010000”，即为只开启尾部灯光的所对应的配电报文。对于配电报文，可以首先采用第一时间间隔快发三帧，完成控制指令的“告知”。在快发三帧后，可以以第二时间间隔，周期性的进行发送，以使被控部件执行控制指令，从而完成精细化电源管理。需要说明的是，第一时间间隔短于第二时间间隔。

表1

对于电源管理而言，中央控制器可以通过微控制单元直接将配电报文发给被控部件，也可以通过微控制单元将配电报文发给被控部件的区域控制器。示例性地，区域控制器可以设置为4个，分别装配于车辆的前侧、左侧、右侧和后侧。每个区域控制器负责将控制指令输出至就近的被控部件。不难理解，区域控制器和被控部件之间的控制关系可以是预先确定的。由此，区域控制器在接收到配电报文后，即可基于配电报文完成对被控部件的供电控制。

在一种实施方式中，通信管理，具体包括：

在接收到寻址请求的情况下，将寻找请求转发至区域控制器；区域控制器用于对车辆的被控部件进行控制；区域控制器为多个，设置于车辆的不同位置；

中央控制器根据区域控制器反馈的状态报文识别被控部件。

结合图2所示，寻址请求可以包括用户主动触发而生成的，也可以是映射触发而生成的。例如，如果用户手动开启对某个被控设备的控制，则寻址请求可以对应用户主动触发而生成的。如果是自动开启对某个被控设备的控制，如车门自锁或自动雨刷等，则寻址请求可以对应映射触发而生成的。

示例性地，图2所示为用户通过影音娱乐模块的交互界面主动触发而生成的寻址请求。中央控制器接收到寻址请求后，发送至区域控制器。区域控制器在接收到寻址请求后，会向所管辖的被控部件发送上电指令。该上电指令用于检测被控部件的状态而非驱动被控部件进行动作。检测被控部件的状态可以依赖于获取被控部件的状态报文而实现。状态报文中通常会包含被控部件的标识信息、自检信息等内容。通过标识信息，可以完成对被控部件的识别，通过自检信息可以了解被控部件当前状态，例如是否正常可用等。区域控制器在获取到所管辖的所有被控部件的状态报文后，会反馈给中央控制器，由此完成通信过程。进一步的，中央控制器在接收到状态报文后，还可以向其他功能板卡进行同步。

在一种实施方式中，中央控制器还用于：

根据识别的结果，确定被控部件的更新需求；

在更新需求为需要更新的情况下，控制执行车联网功能的板卡下载待更新的内容。

识别结果可以包括确定识别出的被控部件为新增加的被控部件，也可以包括识别出的被控部件为已有的被控部件。对于新增加的被控部件，更新需求可以是获取驱动程序，以使得新增加的被控部件可以正常使用。对于已有的被控部件，更新需求可以是检查是否存在软件更新包等。

由此，仍然结合图2所示，在根据识别的结果确定出被控部件的更新请求后，即可将更新请求发送给执行车联网功能的板卡。由执行车联网功能的板卡针对更新请求，在指定地址下载待更新的内容。指定地址可以是车企的软件库、被控部件发布方的软件库或者被信任的第三方软件库等。图2所示示例微通过汽车远程服务提供商(TSP，TelematicsService Provider)发送下载请求，以进行数据下载。利用下载数据进行更新后，可以将更结果告知给执行影音娱乐功能的板卡、执行智能驾驶功能的板卡以及中央控制器。

由此，可以完成被控部件的兼容驱动或者更新。

在一种实施方式中，状态报文的生成过程，包括：

区域控制器根据寻址请求，驱动电源供电指定时长；电源为区域控制器可控的电源；

区域控制器根据通电后各被控对象反馈的信息生成状态报文。

区域控制器在接收到寻址请求后，会向所管辖的被控部件发送上电指令。该上电指令用于检测被控部件的状态而非驱动被控部件进行动作。检测被控部件的状态可以依赖于获取被控部件的状态报文而实现。状态报文中通常会包含被控部件的标识信息、自检信息等内容。通过标识信息，可以完成对被控部件的识别，通过自检信息可以了解被控部件当前状态，例如是否正常可用等。由此，可以收集到区域控制器所管辖的所有被控部件的状态报文。如果是新插接的被控部件，那么中央控制器根据与前次针对寻址请求反馈得到的状态报文进行比对，即可根据新增的标识信息完成对新插接的被控部件的识别。如果是已有的被控部件，也可以根据自检信息完成对被控部件状态的获取。

在一种实施方式中，中央控制器包括中控模块和域控模块；

中控模块用于指令的生成和仲裁；

域控模块用于指令的发送；发送的对象包括功能板卡和第二类功能的执行端；

域控模块还用于中控模块和域控模块的时钟管理，以及用于账号管理，账号对应第一类功能和/或第二类功能的权限和个性化设置。

结合图3所示，本申请中的中央控制器包括中控模块和域控模块。其中，中控模块可以看做是整个车辆的大脑，用于指令的生成和仲裁。中控模块的内部架构遵从分层设计，从下向上依次为：内核层、系统服务层、框架层和应用层。内核层采用linux内核对上层提供基础的内核能力。系统服务层通过框架层对应用程序提供服务，包括平台基础能力子系统集、基础服务子系统集、核心服务子系统集和网路与信息安全子系统集等。平台基础能力子系统集为应用在中央控制器上的运行、调度、迁移等操作提供了基础能力。基础服务子系统集为中央控制器提供公共的、通用的软件服务，由电源管理子系统、日志服务子系统、数据管理子系统等组成。框架层提供了UI框架(例如适用于Java语言的Java UI框架)，以及各种软硬件服务对外开放的多语言框架API。应用层提供与用户交互的能力。即，通过中控模块，可以完成对车辆各部件以及功能板卡的感知以及控制指令的生成。控制指令的生成包含自动生成的控制指令，以及用户下达的控制指令。此外，当控制指令为多个时，还可以对控制指令的优先级进行仲裁，对控制指令的必要性进行仲裁，对控制指令是否正确进行仲裁等。

域控模块包括应用层，域控模块可以通过PCIe与中控模块通信，完成数据交互。域控模块对中控模块过来的命令，进行分发到对应的功能板卡或者第二类功能的各个执行端。

域控模块还可以用于时钟管理。在相关技术中，由于存在多个域控制器，因此如何对各域控制器的时钟管理始终是一个难题。通常各个域计算平台自身进行时钟管理，但由于域计算平台较多，还需要进行时钟统一。在本申请中，只设置一个域控制器，用于完成控制指令的分发以及与主控模块的交互。由此，只需在域控制器执行时钟管理，对各功能板卡和主控模块进行时钟同步，从而可以完成整个车辆的时钟管理，做到统一。

域控模块还可以用于账号管理，账号对应第一类功能和/或第二类功能的权项或个性化设置。例如，同一辆家庭乘用车，家庭中两个用户各有一个账号。由此，可以在域控模块进行账号管理，例如每个记录账号对应的权限和/或个性化设置。由于域控模块的启动时长显著短于主控模块的启动时长，因此，利用域控模块进行账号管理，可以在账号的权限管控和个性化设置层面答复提高效率。

此外，由于域控模块可以作为中控模块与功能板卡或者中控模块与者第二类功能的各个执行端之间的桥梁，因此，还可以在域控模块进行日志管理。例如记录如整车信号等实时系统，将日志格式化压缩后，发送至云端存储。进一步的，还可以在域控模块集成诊断服务，对日志进行故障诊断。

在上述实施例的基础上，本申请还提供一种车辆，上述车辆包括车辆本体以及上述任意一个实施例中的应用于车辆的车辆控制架构，其中，上述应用于车辆的车辆控制架构设置在上述车辆本体中。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包括于本申请的至少一个实施例或示例中。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。

流程图中描述的或在此以其他方式描述的任何过程或方法可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分。并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能。

在流程图中描述的或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。

应理解的是，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。上述实施例方法的全部或部分步骤是可以通过程序来指令相关的硬件完成，该程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。上述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读存储介质中。该存储介质可以是只读存储器，磁盘或光盘等。

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

Claims (10)

1.一种车辆控制架构，其特征在于，包括设置有多个槽位的主板，所述主板通过所述槽位插接中央控制器和功能板卡，所述功能板卡用于控制所述车辆执行第一类功能，所述第一类功能是根据功能对算力的需求和功能迭代的速度进行划分的；功能板卡为多个，每一个功能板卡执行的第一类功能彼此不同；

所述中央控制器用于将获取到的参数转发至所述功能板卡；所述参数是所述功能板卡执行所述第一类功能所需的；

所述中央控制器还用于利用预先集成的控制指令集，控制所述车辆执行第二类功能；所述第二类功能为车辆所执行的除第一类功能以外的功能。

2.根据权利要求1所述的车辆控制架构，其特征在于，所述中央控制器将获取到的参数转发至所述功能板卡，具体包括：

确定待获取参数的属性；所述属性是根据所述待获取参数的数据量和实时性要求确定的；

选择与所述属性匹配的传输协议；

利用选择出的传输协议获取所述参数。

3.根据权利要求1所述的车辆控制架构，其特征在于，所述中央控制器和功能板卡共用所述主板的微控制单元，所述中央控制器利用所述微控制单元执行对所述功能板卡的供电管理和通信管理。

4.根据权利要求1所述的车辆控制架构，其特征在于，所述功能板卡包括执行智能驾驶功能的板卡、执行影音娱乐功能的板卡和执行车联网功能的板卡中的至少一种。

5.根据权利要求4所述的车辆控制架构，其特征在于，所述供电管理，具体包括：

根据所述车辆的状态，确定对被控部件的控制指令；

选择包含所述被控部件的编码表；所述编码表是预先构建的，存储有所述被控部件以及所述被控部件的编码；

利用所述编码表，生成与所述控制指令对应的配电报文；所述配电报文用于所述供电管理。

6.根据权利要求4所述的车辆控制架构，其特征在于，所述通信管理，具体包括：

在接收到寻址请求的情况下，将所述寻找请求转发至区域控制器；所述区域控制器用于对车辆的被控部件进行控制；所述区域控制器为多个，设置于所述车辆的不同位置；

所述中央控制器根据所述区域控制器反馈的状态报文识别被控部件。

7.根据权利要求6所述的车辆控制架构，其特征在于，所述中央控制器还用于：

根据识别的结果，确定所述被控部件的更新需求；

在所述更新需求为需要更新的情况下，控制执行车联网功能的板卡下载待更新的内容。

8.根据权利要求6所述的车辆控制架构，其特征在于，所述状态报文的生成过程，包括：

区域控制器根据所述寻址请求，驱动电源供电指定时长；所述电源为所述区域控制器可控的电源；

区域控制器根据通电后各被控对象反馈的信息生成状态报文。

9.根据权利要求1至8任一所述的车辆控制架构，其特征在于，所述中央控制器包括中控模块和域控模块；

所述中控模块用于指令的生成和仲裁；

所述域控模块用于所述指令的发送；所述发送的对象包括所述功能板卡和所述第二类功能的执行端；

所述域控模块还用于所述中控模块和所述域控模块的时钟管理，以及用于账号管理，所述账号对应所述第一类功能和/或所述第二类功能的权限和个性化设置。

10.一种车辆，其特征在于，所述车辆包括车辆本体以及如权利要求1至9中任一项所述的应用于车辆的车辆控制架构，所述应用于车辆的车辆控制架构设置在所述车辆本体中。