一种多场景引擎的系统架构、车辆控制系统及车辆的制作方法

1.本技术涉及汽车智能化技术领域，尤其涉及一种多场景引擎的系统架构、车辆控制系统及车辆。


背景技术：

2.在汽车信息处理领域，soa(service-oriented architecture，面向服务架构)服务作为实现服务部署分离、服务高内聚、功能可复用的底层逻辑，为用户提供了可编辑、场景可编排的用户自定义汽车的能力，但要执行相关的能力，需要部署场景引擎，由场景引擎来执行任务。
3.目前场景引擎预先部署在车上，场景引擎的部署位置通常为ivi(in-vehicle infotainment，信息娱乐系统)或其他算力够高能够满足场景引擎落地的零部件上，此时场景引擎的部署位置不可更改，场景引擎无法灵活部署，一旦场景引擎出现故障无法为车辆提供智能服务，轻则影响乘客体验，重则影响行驶安全。
4.因此，如何提供一种解决上述技术问题的方案是目前本领域技术人员需要解决的问题。


技术实现要素：

5.有鉴于此，本技术实施例提供了一种多场景引擎的系统架构、车辆控制系统及车辆，以解决现有技术中场景引擎无法灵活部署的问题。
6.本技术实施例的第一方面，提供了一种多场景引擎的系统架构，应用于汽车，包括：
7.包括多个互相连接的场景引擎，多个场景引擎包括一个主引擎、一个或多个备用引擎；
8.主引擎用于执行当前车辆的任务动作，并将数据同步到备用引擎；
9.备用引擎用于监测主引擎的工作状态，在监测到主引擎的工作状态异常时，利用备用引擎替换主引擎作为新的主引擎，并执行当前车辆的任务动作。
10.本技术实施例的第二方面，提供了一种车辆控制系统，包括如上述多场景引擎的系统架构。
11.本技术实施例的第三方面，提供了一种车辆，包括如上述车辆控制系统。
12.本技术实施例与现有技术相比存在的有益效果至少包括：本技术实施例通过多个相互连接的场景引擎，设置主引擎执行任务动作、备用引擎监测主引擎的工作状态，当监测到主引擎工作状态异常时利用备用引擎替换主引擎并执行原本主引擎的任务动作，备用引擎和主引擎之间的替换对用户无感知，消除了原本场景引擎故障时无法为车辆提供智能服务的隐患，更加灵活可靠。
附图说明
13.为了更清楚地说明本技术实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。
14.图1是本技术实施例的一种多场景引擎的系统架构的场景示意图；
15.图2是本技术实施例提供的一种具体的多场景引擎的系统架构的流程示意图；
16.图3是本技术实施例提供的一种电子设备的结构示意图。
具体实施方式
17.以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本技术实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本技术。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本技术的描述。
18.下面将结合附图详细说明根据本技术实施例的一种多场景引擎的系统架构、车辆控制系统及车辆。
19.图1是本技术实施例提供的一种多场景引擎的系统架构。图1的系统架构应用于汽车。如图1所示，该系统架构包括：
20.包括多个互相连接的场景引擎，多个场景引擎包括一个主引擎101、一个或多个备用引擎102；
21.主引擎101用于执行当前车辆的任务动作，并将数据同步到备用引擎102；
22.备用引擎102用于监测主引擎101的工作状态，在监测到主引擎101的工作状态异常时，利用备用引擎102替换主引擎101作为新的主引擎，并执行当前车辆的任务动作。
23.由于主引擎101在执行当前车辆的任务动作时将数据同步到了备用引擎102，因此一旦备用引擎102监测到主引擎101的工作状态异常，则可替换原本的主引擎101作为新的主引擎根据同步的数据执行当前车辆的任务动作，主引擎的数据同步和切换，提供了场景引擎的冗余备份保护，即使当前主引擎出现崩溃或异常，依然能够由备份引擎继续执行任务动作，避免了唯一的场景引擎导致任务中止的情况发生，车辆和用户对原主引擎的故障和备用引擎的切换均无感知，整个系统架构为车辆提供了稳定可靠的关于场景引擎的支持服务。
24.系统架构可包括一个备用引擎102或多个备用引擎102。当备用引擎102只有一个时，该备用引擎102用于监测主引擎101的工作状态，并在监测到主引擎101的工作状态异常时，将自身作为新的主引擎替换故障的主引擎101，接替原本主引擎101执行当前车辆的任务动作。该情况下，系统架构中的两个场景引擎通常分别设置于智能座舱和智能网关中，其中设于智能座舱的场景引擎默认作为主引擎101，设于智能网关的场景引擎默认作为备用引擎102。
25.当备用引擎102有多个时，每个备用引擎102均可监测主引擎101的工作状态，当监测到主引擎的工作状态异常，从所有的备用引擎102确定一个目标备用引擎作为新的主引擎。需要注意的是，所有的场景引擎，在同一时刻，用于执行当前车辆的任务动作的主引擎
只有一个，多个备用引擎102确定目标备用引擎的过程，可以是状态正常的备用引擎之间通讯并推选出一个备用引擎作为目标备用引擎，也可以由每个备用引擎102自主根据各场景引擎逐级递减的应用优先级判断自身是否为目标备用引擎来得出所有场景引擎中要执行当前车辆的任务动作的主引擎。具体的，每个场景引擎均预先设有不同级别的应用优先级，主引擎101为状态正常的所有场景引擎中应用优先级最高的场景引擎；相应的，利用备用引擎102替换主引擎101作为新的主引擎的过程，包括：在状态正常的所有备用引擎102中确定应用优先级最高的备用引擎102作为新的主引擎。
26.备用引擎102监测主引擎101的工作状态时，主要监测与主引擎101的连接状态是否正常或主引擎101是否发出了主备切换指令，因此监测主引擎101的工作状态的过程，包括：监测主引擎101的工作状态，判断工作状态是否满足异常条件；异常条件包括：与主引擎101的连接状态异常，或，接收到主引擎101发送的主备切换指令；若是，判定主引擎101状态异常；若否，判定主引擎101状态正常。
27.其中，与主引擎101的连接状态异常，包括：主引擎101发送的心跳包存在超时情况，或，主引擎101发送的用于数据同步的数据包存在超时情况。已知场景引擎之间互相连接，主引擎101将定时向备用引擎102发送心跳包，一旦备用引擎102未在规定时间内收到主引擎101发送的心跳包，也即心跳包存在超时情况，就可以确定该备用引擎102与主引擎101的连接状态异常。当主引擎101执行当前车辆的任务动作时，同时将任务动作相关的数据以数据包的形式同步到备用引擎102，如果同步过程中原本应当按照预设频次发送用于数据同步的数据包出现超时情况，同样可确定该备用引擎102与主引擎101的连接状态异常。
28.除了备用引擎102根据接收的心跳包或数据包来判断与主引擎101的连接状态是否正常外，备用引擎102还可接收主引擎101主动发送的主备切换指令，通常主引擎101生成主备切换指令的触发条件为主引擎101自身的服务通讯网络出现异常，也就是说主引擎101还用于：监测自身所在的服务通讯网络是否正常；若否，向备用引擎102发送主备切换指令。除了与其他场景引擎连接外，每个场景引擎向上和向下均连接有其他通讯对象，这些通讯对象构成每个场景引擎的服务通讯网络，主引擎101监测自身所在的服务通讯网络是否正常，当存在通讯对象无法连接，则主引擎101的服务通讯网络不正常，主引擎101无法正常与服务通讯网络中的通讯对象联系，此时主动向备用引擎102发送主备切换指令，以提示备用引擎102尽快替换主引擎来执行当前任务动作，避免任务动作中断，确保系统架构对车辆的服务支持的稳定性。
29.在每个场景引擎的服务通讯网络中，向上的通讯对象包括云端平台、更高层控制系统，向下的通讯对象包括一个或多个ecu(electronic control unit，电子控制器单元)，每个场景引擎分别与云端平台、ecu连接。
30.以一个主引擎和一个备用引擎为例，图2是本技术实施例提供的一种多场景引擎的系统架构的结构示意图。如图2所示，每个场景引擎均包括：
31.与ecu连接的linux bsp层；
32.与linux bsp层连接的服务层，服务层包括soa服务和s2s服务中的一个或多个；
33.与服务层连接的执行层，执行层用于进行数据同步、执行任务动作或任务逻辑。
34.bsp(board support package，板级支持包)是介于主板硬件和操作系统之间的系统软件之一，主要目的是为了支持操作系统，使之能够更好的运行于硬件主板。bsp是相对
于操作系统而言的，不同的操作系统对应于不同定义形式的bsp。本实施例中操作系统为linux系统，因此在场景引擎中设计linux bsp层与ecu连接，具体通过some/ip(scalable service-oriented middleware over ip)协议或者dds(data distribution service数据分发服务)协议建立连接关系。
35.每个场景引擎中，soa服务用于接收执行层在执行任务动作时的任务指令，并根据任务指令调用相应的服务接口，以执行任务指令。对车辆而言，在特定的时间和空间中，当一个或多个事件发生时，就形成了通常所说的用车场景。智能汽车的发展趋势是能够更有效地识别用车场景甚至预测用车场景，并且主动通过各种服务来满足客户用车需求。智能的本质就是具有自主性甚至预测性，并且这种自主性和预测性的能力能够在不断的自我进化中得到提升，更好地满足用车需求。
36.基于该发展趋势，soa服务可包括场景感知类服务、控制决策类服务、动作执行类服务。
37.场景感知类服务主要用于用车场景的感知，即对时间、空间以及发生事件的感知，时间感知服务，例如通过4g网络获取时间信息；空间感知服务，例如通过gps天线获取位置信息；事件感知类服务，例如车辆上电感知、车辆换挡感知、环境温度感知、驾驶员表情感知、驾驶员视线感知。场景感知服务主要是基于车辆硬件配置来实现的。场景感知类服务属于基础服务，可以等同于传统的感知类功能，soa服务根据任务指令调用场景感知类服务，可返回相应的场景感知信息，执行层将根据返回信息作进一步的处理。
38.控制决策类服务是造就智能汽车的核心服务，它根据场景感知类服务以及用户操作所提供的各种输入，经过分析和计算，最终决定车辆应该以何种方式满足客户的用车需求。对于控制决策类服务而言，能多大程度地减少对于用户操作输入的依赖，能多大程度地充分利用场景感知类服务输入、并将各种输入通过强大的算力进行综合分析计算、完成最终的控制决策，是判断控制决策类服务智能化程度高低的依据。例如车内氛围灯的颜色可以根据用户心情自主调节，用户吃饭的餐厅可以根据用户的口味、综合最新的餐厅优惠折扣活动自主推荐，车内温度、湿度、空气质量可以根据用户身体状态、当前天气情况自主调节。控制决策类服务依赖于算法和控制策略，并且这种算法和控制策略自身也可以不断进化，主要基于软件来实现。从服务与功能的关系来理解，控制决策类服务属于高级服务，它可以灵活调用和组合基础服务完成不同的任务，满足不同场景的用车需求。
39.动作执行类服务主要是用于控制车辆执行各种动作，包括所有用户可以感知到的声音，文字、图像、电机动作等等。动作执行类服务主要是基于整车硬件配置来实现的。从服务与功能的关系来理解，动作执行类服务也属于基础服务，可以等同于传统的动作执行类功能。
40.每个场景引擎中包括一个或多个可响应的soa服务，每个soa服务均可接收执行层在执行任务动作时的任务指令，并根据任务指令调用相应的服务接口，以执行任务指令，场景引擎根据需求不断地调用soa服务，可实现车内场景的感知、车上场景的控制、车辆动作的执行等应用场景。
41.在服务层以soa服务建立架构之后，还存在一个待解决的问题是，基于以太网的服务(service)的域控制器、区域控制器等，如何能和只有基于信号(signal)工作的ecu相互兼容并工作，由此加入s2s(signal to service，信号转服务)服务，来解决该问题。
42.根据上述关于场景引擎的描述，执行层设有数据同步程序模块，用于通过socket与另一个场景引擎的数据同步程序模块进行数据同步。执行层还设有模型解析程序模块、事件感知程序模块、冲突对策程序模块、动作执行程序模块、数据收集程序模块、车云数据交互程序模块、场景列表分发程序模块，这些模块共同工作以执行动作任务或任务逻辑，主引擎和备用引擎使用同一份云端平台的token，当该场景引擎为主引擎，则执行任务动作，车云数据交互程序模块执行车云交互动作即车云通信，当该场景引擎为备用引擎，则执行任务逻辑，车云数据交互程序模块空闲连接。
43.在每个场景引擎中，除了linux bsp层、服务层和执行层外，还包括通信中间层，包括通信服务总线模块和通信协议封装模块，以实现执行层和服务层之间的信息传递。
44.如图2所示的场景引擎的结构示意图，对于主引擎101的工作状态异常的判定，包括以下几种情况：
45.一种是主引擎101作为工作引擎，主引擎101产生进程崩溃或ecu崩溃，数据同步长时间超时，导致主引擎101和备用引擎102断开连接，原本主引擎101作为socket服务器端，备用引擎102作为socket客户端，当备用引擎102收不到心跳包或用于数据同步的数据包的持续时间达到超时时间阈值，判定主引擎的工作状态异常，应用优先级最高的备用引擎102将自身切换为主引擎，切换后如果有场景的相关配置在原来的主引擎101执行，原备用引擎即当前主引擎放开执行屏蔽，以屏蔽原工作引擎上的后续执行动作，当前主引擎接着执行剩余的任务动作，并且同步连接到云端平台进行车云通信，通过车云通信交互上报告警信息和完成切换的信息。
46.另一种是主引擎101产生服务总线告警，例如长时间收不到event事件，判定主引擎101发生故障，主引擎101将自身切换为备用引擎，并通过数据同步程序模块同步事件超时对应的告警信息到备用引擎102，告警信息作为主备切换指令发送到备用引擎102，备用引擎102确定当前主引擎101状态异常并替换主引擎，切换成功后如果有场景的相关配置在以前的主引擎执行，那么原备用引擎即当前主引擎放开执行屏蔽并接着执行剩余的动作，并且同步连接到云端中台进行车云通信，通过车云通信交互上报告警信息和完成切换的信息。
47.如果原本故障的主引擎通过重启恢复或通信恢复，则socket服务器端和socket客户端之间的通信恢复，服务总线通信恢复，原本故障的主引擎数据同步完成后，状态稳定到预设阈值后，通过数据同步程序模块对原备用引擎同步无告警信息和切换请求，当前工作的主引擎(此时原备用引擎作为当前工作的主引擎执行任务动作)收到切换请求后暂停当前场景执行，主动向已恢复的原故障的主引擎发送同步数据并告知已经切换，已恢复的原故障的主引擎收到切换信息后替换当前工作的主引擎开始执行任务动作，并通过车云通信交互上报恢复切换的信息。
48.除了以上场景，当只存在一个状态正常的场景引擎，该场景引擎可以是默认的主引擎或默认的备用引擎，但此处作为执行任务动作的主引擎，没有第二个场景引擎可以切换，一旦出现故障无法进行备份切换，此时通过车云数据交互程序模块上报切换失败信息。
49.本实施例中系统架构的场景引擎，可通过设置于车辆中的预配置文件实现，在根据车型配置参数对预配置文件进行预编译操作后，即可在车辆中配置对应车型配置参数的系统架构。该配置动作具有自适应特性，不需人工分析具体的车型后人工将编译好的文件
程序部署车内，研发和配置效率更高。其中，当前车辆的车型配置参数包括当前车辆的硬件参数、软件参数等，具体可根据每种场景引擎的实际情况设置用于区分场景引擎种类的车型配置参数。根据车型配置参数配置相应的场景引擎时，不同的车型配置参数，对应配置的场景引擎不同，具体包括场景引擎的个数不同、每个场景引擎的结构或性能不同等。
50.例如不同车型配置参数对应场景引擎的性能不同，低性能处理器只足够提供支持低性能场景引擎的硬件环境，高性能处理器能够提供支持高性能场景引擎和低性能场景引擎的硬件环境，通常选择根据车型配置参数确定的当前硬件环境支持的最高性能的场景引擎。
51.例如不同车型配置参数对应的场景引擎的个数不同时，不同个数的场景引擎情况包括单场景引擎、双场景引擎和多场景引擎，这些场景引擎中至少包括一个主引擎。当车型配置参数对应多场景引擎，通常在配置场景引擎时对每个场景引擎设置不同级别的优先应用级，以保证场景引擎在运行时不发生冲突，例如多个场景引擎包括一个主引擎、一个或多个备用引擎；其中主引擎用于执行当前车辆的任务动作，备用引擎与主引擎的数据同步，每个备用引擎只用于执行当前车辆的任务逻辑。此时备用引擎不执行任务动作，但需要同时执行任务逻辑，从而提高备用引擎作为主引擎的热备用的切换效率，更便于在主引擎发生故障时实现不被用户感知的快速切换。
52.本技术实施例通过多个相互连接的场景引擎，设置主引擎执行任务动作、备用引擎监测主引擎的工作状态，当监测到主引擎工作状态异常时利用备用引擎替换主引擎并执行原本主引擎的任务动作，备用引擎和主引擎之间的替换对用户无感知，消除了原本场景引擎故障时无法为车辆提供智能服务的隐患，更加灵活可靠。
53.上述所有可选技术方案，可以采用任意结合形成本技术的可选实施例，在此不再一一赘述。
54.相应的，本技术实施例还公开了一种车辆控制系统，包括一种多场景引擎的系统架构，该系统架构应用于汽车，包括多个互相连接的场景引擎，多个场景引擎包括一个主引擎、一个或多个备用引擎；
55.主引擎用于执行当前车辆的任务动作，并将数据同步到备用引擎；
56.备用引擎用于监测主引擎的工作状态，在监测到主引擎的工作状态异常时，利用备用引擎替换主引擎作为新的主引擎，并执行车辆的任务动作。
57.由于主引擎在执行当前车辆的任务动作时将数据同步到了备用引擎，因此一旦备用引擎监测到主引擎的工作状态异常，则可替换原本的主引擎作为新的主引擎根据同步的数据执行当前车辆的任务动作，主引擎的数据同步和切换，提供了场景引擎的冗余备份保护，即使主引擎出现崩溃或异常，依然能够由备份引擎继续执行任务动作，避免了唯一的场景引擎导致任务中止的情况发生，车辆和用户对原主引擎的故障和备用引擎的切换无感知，整个系统架构为车辆提供了稳定可靠的关于场景引擎的支持服务。
58.在一些具体的实施例中，每个场景引擎均预先设有不同级别的应用优先级，主引擎为状态正常的所有场景引擎中应用优先级最高的场景引擎；
59.相应的，利用备用引擎替换主引擎作为新的主引擎的过程，包括：
60.在状态正常的所有备用引擎中确定应用优先级最高的备用引擎作为新的主引擎。
61.在一些具体的实施例中，监测主引擎的工作状态的过程，包括：
62.监测主引擎的工作状态，判断工作状态是否满足异常条件；异常条件包括：与主引擎的连接状态异常，或，接收到主引擎发送的主备切换指令；
63.若是，判定主引擎状态异常；
64.若否，判定主引擎状态正常。
65.在一些具体的实施例中，与主引擎的连接状态异常，包括：
66.主引擎发送的心跳包存在超时情况，或，主引擎发送的用于数据同步的数据包存在超时情况。
67.在一些具体的实施例中，主引擎还用于：
68.监测自身所在的服务通讯网络是否正常；若否，向备用引擎发送主备切换指令。
69.在每个场景引擎的服务通讯网络中，向上的通讯对象包括云端平台、更高层控制系统，向下的通讯对象包括一个或多个ecu(electronic control unit，电子控制器单元)，每个场景引擎分别与云端平台、ecu连接。
70.在一些具体的实施例中，每个场景引擎均包括：
71.与ecu连接的linux bsp层；
72.与linux bsp层连接的服务层，服务层包括soa服务和s2s服务中的一个或多个；
73.与服务层连接的执行层，执行层用于进行数据同步、执行任务动作或任务逻辑。
74.bsp(board support package，板级支持包)是介于主板硬件和操作系统之间的系统软件之一，主要目的是为了支持操作系统，使之能够更好的运行于硬件主板。bsp是相对于操作系统而言的，不同的操作系统对应于不同定义形式的bsp。本实施例中操作系统为linux系统，因此在场景引擎中设计linux bsp层与ecu连接，具体通过some/ip(scalable service-oriented middleware over ip)协议或者dds(data distribution service数据分发服务)协议建立连接关系。
75.在一些具体的实施例中，每个场景引擎中，soa服务用于接收执行层在执行任务动作时的任务指令，并根据任务指令调用相应的服务接口，以执行任务指令。
76.每个场景引擎中包括一个或多个可响应的soa服务，每个soa服务均可接收执行层在执行任务动作时的任务指令，并根据任务指令调用相应的服务接口，以执行任务指令，场景引擎根据需求不断地调用soa服务，可实现车内场景的感知、车上场景的控制、车辆动作的执行等应用场景。
77.在服务层以soa服务建立架构之后，还存在一个待解决的问题是，基于以太网的服务(service)的域控制器、区域控制器等，如何能和只有基于信号(signal)工作的ecu相互兼容并工作，由此加入s2s(signal to service信号转服务)服务，来解决该问题。
78.根据上述关于场景引擎的描述，执行层设有数据同步程序模块，用于通过socket与另一个场景引擎的数据同步程序模块进行数据同步。执行层还设有模型解析程序模块、事件感知程序模块、冲突对策程序模块、动作执行程序模块、数据收集程序模块、车云数据交互程序模块、场景列表分发程序模块，这些模块共同工作以执行动作任务或任务逻辑，主引擎和备用引擎使用同一份云端平台的token，当该场景引擎为主引擎，则执行任务动作，车云数据交互程序模块执行车云交互动作即车云通信，当该场景引擎为备用引擎，则执行任务逻辑，车云数据交互程序模块空闲连接。
79.在每个场景引擎中，除了linux bsp层、服务层和执行层外，还包括通信中间层，包
括通信服务总线模块和通信协议封装模块，以实现执行层和服务层之间的信息传递。
80.本技术实施例通过多个相互连接的场景引擎，设置主引擎执行任务动作、备用引擎监测主引擎的工作状态，当监测到主引擎工作状态异常时利用备用引擎替换主引擎并执行原本主引擎的任务动作，备用引擎和主引擎之间的替换对用户无感知，消除了原本场景引擎故障时无法为车辆提供智能服务的隐患，更加灵活可靠。
81.相应的，本技术实施例还公开了一种车辆，包括如上文任一项实施例所述的车辆控制系统。其中，本实施例中车辆控制系统的具体细节，可以参照上文实施例中相关的描述内容，此处不再赘述。本实施例中车辆具有与上文实施例中车辆控制系统相同的技术效果，此处不再赘述。
82.图3是本技术实施例提供的电子设备3的示意图。如图3所示，该实施例的电子设备3包括：处理器301、存储器302以及存储在该存储器302中并且可在处理器301上运行的计算机程序303。处理器301执行计算机程序303时实现上述各实施例中各场景引擎的功能。
83.电子设备3可以是车辆的车机电脑，车机电脑与服务器或终端设备联网。本领域技术人员可以理解，图3仅仅是电子设备3的示例，并不构成对电子设备3的限定，可以包括比图示更多或更少的部件，或者不同的部件。
84.处理器301可以是中央处理单元(central processing unit，cpu)，也可以是其它通用处理器、数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现场可编程门阵列(field-programmable gate array，fpga)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。
85.存储器302可以是电子设备3的内部存储单元，例如，电子设备3的硬盘或内存。存储器302也可以是电子设备3的外部存储设备，例如，电子设备3上配备的插接式硬盘，智能存储卡(smart media card，smc)，安全数字(secure digital，sd)卡，闪存卡(flash card)等。存储器302还可以既包括电子设备3的内部存储单元也包括外部存储设备。存储器302用于存储计算机程序以及电子设备所需的其它程序和数据。
86.所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
87.集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中。计算机程序可以包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。计算机可读存储介质可以包括：能够携带计算机程序代码的任何实体或装置、记录介质、u盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(read-only memory，rom)、随机存取存储器(random access memory，ram)、电载波信号、电信信号以及软件分发介质等。需要说明的是，计算机可读存储介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如，在某些司法管辖区，根据立法和专利实践，计算机可读存储介质不包括电载波信号和
电信信号。
88.以上实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的精神和范围，均应包含在本技术的保护范围之内。

技术特征：
1.一种多场景引擎的系统架构，其特征在于，应用于汽车，包括多个互相连接的场景引擎，多个所述场景引擎包括一个主引擎、一个或多个备用引擎；所述主引擎用于执行当前车辆的任务动作，并将数据同步到所述备用引擎；所述备用引擎用于监测所述主引擎的工作状态，在监测到所述主引擎的工作状态异常时，利用所述备用引擎替换所述主引擎作为新的主引擎，并执行所述车辆的任务动作。2.根据权利要求1所述的系统架构，其特征在于，每个所述场景引擎均预先设有不同级别的应用优先级，所述主引擎为状态正常的所有所述场景引擎中应用优先级最高的所述场景引擎；相应的，利用所述备用引擎替换所述主引擎作为新的主引擎的过程，包括：在状态正常的所有所述备用引擎中确定应用优先级最高的所述备用引擎作为新的主引擎。3.根据权利要求1所述的系统架构，其特征在于，监测所述主引擎的工作状态的过程，包括：监测所述主引擎的工作状态，判断所述工作状态是否满足异常条件；所述异常条件包括：与所述主引擎的连接状态异常，或，接收到所述主引擎发送的主备切换指令；若是，判定所述主引擎状态异常；若否，判定所述主引擎状态正常。4.根据权利要求3所述的系统架构，其特征在于，与所述主引擎的连接状态异常，包括：所述主引擎发送的心跳包存在超时情况，或，所述主引擎发送的用于数据同步的数据包存在超时情况。5.根据权利要求3所述的系统架构，其特征在于，所述主引擎还用于：监测自身所在的服务通讯网络是否正常；若否，向所述备用引擎发送所述主备切换指令。6.根据权利要求1所述的系统架构，其特征在于，每个所述场景引擎分别与云端平台、ecu连接。7.根据权利要求1至6中任一项所述的系统，其特征在于，每个所述场景引擎均包括：与ecu连接的linux bsp层；与所述linux bsp层连接的服务层，所述服务层包括soa服务和s2s服务中的一个或多个；与所述服务层连接的执行层，所述执行层用于进行数据同步、执行任务动作或任务逻辑。8.根据权利要求7所述的系统架构，其特征在于，每个所述场景引擎中，所述soa服务用于接收所述执行层在执行任务动作时的任务指令，并根据所述任务指令调用相应的服务接口，以执行所述任务指令。9.一种车辆控制系统，其特征在于，包括如权利要求1至8任一项所述的多场景引擎的系统架构。10.一种车辆，其特征在于，包括如权利要求9所述的车辆控制系统。

技术总结
本申请涉及汽车智能化技术领域，提供了一种多场景引擎的系统架构、车辆控制系统及车辆。该系统架构应用于汽车，包括多个互相连接的场景引擎，多个场景引擎包括一个主引擎、一个或多个备用引擎；主引擎用于执行当前车辆的任务动作，并将数据同步到备用引擎；备用引擎用于监测主引擎的工作状态，在监测到主引擎的工作状态异常时，利用备用引擎替换主引擎作为新的主引擎，并执行当前车辆的任务动作。本申请通过多个相互连接的场景引擎，消除了原本场景引擎故障时无法为车辆提供智能服务的隐患，更灵活可靠。更灵活可靠。更灵活可靠。


技术研发人员：涂少波 朱乾勇 龙政方
受保护的技术使用者：成都赛力斯科技有限公司
技术研发日：2023.04.20
技术公布日：2023/7/28