CN117775012A - 车载情景模式的定义方法、车载设备及其介质 - Google Patents

Abstract

本申请涉及智能驾驶技术领域，尤其涉及一种车载情景模式的定义方法、车载设备及其介质。本申请的车载情景模式定义方法，为用户提供了半预置的车载情景模式，支持用户根据需求修改半预置的车载情景模式的功能(比如增加或删除功能)。并且，在用户修改功能后，车载设备会对用户修改后的车载情景模式进行有效性检测，包括对修改后的车载情景模式的完备性检测、互斥操作检测等等。在这些检测都通过后，用户才可以使用修改后的车载情景模式，或者说修改后的车载情景模式才可以生效并能被执行。在有效性检测过程中，车载设备会向用户反馈修改后车载情景模式不能生效的原因，以及指导用户应该如何修改，以进一步提高用户体验。

Description

车载情景模式的定义方法、车载设备及其介质

技术领域

本申请涉及智能驾驶技术领域，尤其涉及一种车载情景模式的定义方法、车载设备及其介质。

背景技术

随着智能车辆的广泛使用，用户对于座舱智能化的期望越来越高。为了满足用户在出行驾驶时与座舱交互的需求，各大厂商设计了不同的座舱情景模式。其中，一些座舱情景模式需在满足某些检测条件以及触发条件后，才会提供对应的服务，比如哨兵模式。而一些座舱情景模式只需满足相应的触发条件就可以提供对应的服务，比如小憩模式。

但这些座舱情景模式大多是用户只可使用不可更改的，那么如果用户希望在某个座舱情景模式下增加或减少一些功能，以目前的方案是实现不了的。

发明内容

为了解决上述技术问题，本申请提供了一种车载情景模式的定义方法、车载设备及其计算机可读存储介质。

第一方面，本申请提供了一种车载情景模式的定义方法，应用于第一电子设备，包括：检测到用户针对于目标车载情景模式的修改指令；根据修改指令修改目标车载情景模式，得到修改后的车载情景模式；对修改后的车载情景模式进行有效性检测，并根据检测结果决定是否更新目标车载情景模式，其中，对应于修改后的车载情景模式通过第一电子设备的有效性检测，将目标车载情景模式更新为修改后的车载情景模式。

也即，第一电子设备根据修改指令，修改目标车载情景模式，然后对修改后的目标情景模式进行有效性检测，并且在修改后的目标情景模式通过第一电子设备的有效性检测后，将目标车载情景模式更新为修改后的车载情景模式，或者说修改后的车载情景模式才可以生效并能够被执行。其中，有效性检测包括对修改后的车载情景模式的完备性检测、互斥操作检测等等。通过这种方法，可以避免被修改的车载情景模式在执行过程中失败，提高用户体验。

结合第一方面，在第一方面的一种可能的实现方式中，方法还包括：对应于修改后的车载情景模式未通过第一电子设备的有效性检测，不更新目标车载情景模式。也即，如果修改后的车载情景模式没有通过第一电子设备的有效性检测，则保持原有的目标车载情景模式不变，也就是说不更新目标车载情景模式。通过这种方法，可以保证更新后的目标车载情景模式都是可以被执行的，能够提高用户体验。

结合第一方面以及上述可能的实现方式，在第一方面的一种可能的实现方式中，对修改后的车载情景模式进行有效性检测，包括：确定与修改后的车载情景模式对应的有效性检测条件，根据对应的有效性检测条件，对修改后的车载情景模式进行有效性检测。也即，由于每一种车载情景模式都有不同的功能，所以每一种车载情景模式都有对应的有效性检测条件。在修改目标车载情景模式后，利用与目标车载情景模式对应的有效性检测条件，对修改后的车载情景模式进行检测，以确保更新的目标车载情景模式都能够满足对应的有效性检测条件。

结合第一方面以及上述可能的实现方式，在第一方面的一种可能的实现方式中，有效性检测至少包括对修改后的车载情景模式对应的功能进行完备性检测以及互斥操作检测。

其中，完备性测试指的是对用户修改后的车载情景模式功能的完整性检测，确定修改后的车载情景模式的功能是否仍符合模式设计的逻辑等。比如，对于哨兵模式而言，车辆停放位置的检测功能不可以删除，如果用户出于降低功耗的考虑，删除车辆停放位置的检测功能，那么修改后的哨兵模式就是不符合完备性要求的，也即不能通过有效性检测。再比如，哨兵模式一般具有多种类型的风险检测，比如不明人员靠近风险检测、车门/后备箱开启风险检测、座舱内动静风险检测、车辆倾斜风险检测，而就哨兵模式而言，不明人员靠近风险检测与车门/后备箱开启风险检测二者必须要保留一个，才能确定是不明人员开启车门/后备箱，因此当用户出于其他目的诸如降低功耗的考虑，将不明人员靠近风险检测以及车门/后备箱开启风险检测的功能均删除后，那么修改后的哨兵模式就是不符合完备性要求的，也即不能通过有效性检测。

互斥操作检测指的是针对车辆行驶规范、用户人身安全等，从安全性角度进行的检测。比如，对于儿童遗忘提醒模式，出于安全考虑，用户不能删除禁用语音功能、屏幕点击，防止儿童误触造成危险。

通过上述有效性检测，可以保证更新后的车载情景模式避免因不满足完备性要求或互斥性操作检测，而在执行时出现错误。可以保证更新后的车载情景模式的安全性，提高用户体验。

结合第一方面以及上述可能的实现方式，在第一方面的一种可能的实现方式中，目标车载情景模式至少包括一种情景模式，每个情景模式表示第一电子设备所在车辆中多个设备的特定工作方式的组合。也即，情景模式指的是第一电子设备所在车辆中多个设备的特定工作方式的组合。比如，在哨兵模式的情景模式下，情景模式对应的车辆部件至少包括报警灯和报警音频发声部，工作方式是报警灯闪烁，和报警音频发生部发出报警语音。在洗车模式下，该情景模式对应的车辆部件至少包括车窗、车内充电接口，对应的工作方式是车窗关闭，车内充电接口自动断电。在娱乐模式下，驻车时座椅根据用户体位自动调节、开启车内环绕音效、支持外界娱乐设备，例如游戏手柄等等。

结合第一方面以及上述可能的实现方式，在第一方面的一种可能的实现方式中，目标车载情景模式至少包括以下任一项情景模式：小憩模式、儿童遗落提醒模式、洗车模式、娱乐模式或哨兵模式。

结合第一方面以及上述可能的实现方式，在第一方面的一种可能的实现方式中，方法还包括：在第一电子设备显示修改后的车载情景模式未通过有效性检测的原因。也即，在修改后的车载情景模式没有通过有效性检测的情况下，可以在第一电子设备显示修改后车载情景模式未通过有效性检测的原因，使用户可以根据显示的未通过有效性检测原因做出适应性调整，提高用户体验。

结合第一方面以及上述可能的实现方式，在第一方面的一种可能的实现方式中，方法还包括：将修改后的车载情景模式发送至第二电子设备，其中，被发送的修改后的车载情境模式能够使得第二电子设备更新第二电子设备上的目标车载情景模式。也即，更新目标车载情景模式的过程可以在第一电子设备上进行，也可以在第二电子设备上进行。

结合第一方面以及上述可能的实现方式，在第一方面的一种可能的实现方式中，方法还包括：对应于修改后的车载情景模式未通过第一电子设备的有效性检测，不更新目标车载情景模式，发送第二信息，第二信息用于在第二电子设备上显示修改后的车载情景模式未通过有效性检测的原因。也即，可以在第一电子设备上显示修改后的车载情景模式未通过有效性检测的原因，也可以在第二电子设备显示修改后的车载情景模式未通过有效性检测的原因。

结合第一方面以及上述可能的实现方式，在第一方面的一种可能的实现方式中，第一电子设备包括车载设备，第二电子设备包括智能手机或平板电脑。

结合第一方面以及上述可能的实现方式，在第一方面的一种可能的实现方式中，第一电子设备包括驾驶舱控制器，驾驶舱控制器包括检测模块，检测模块用于对修改后的车载情景模式进行有效性检测。

第二方面，本申请实施例还提供了一种电子设备，该电子设备包括存储器，存储有计算机程序指令；处理器，处理器和存储器耦合，当存储器存储的计算机程序指令被处理器执行时使得电子设备实现上述第一方面以及第一方面的任一种可能的实现方式中任一项的方法或第二方面以及第二方面的任一种可能的实现方式中任一项的方法。

第三方面，本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，其特征在于，计算机程序被处理器执行时实现上述第一方面以及第一方面的任一种可能的实现方式中任一项的方法或第二方面以及第二方面的任一种可能的实现方式中任一项的方法。

第四方面，本申请实施例提供了一种计算机程序产品，当计算机程序产品在电子设备上运行时，使得电子设备执行上述第一方面以及第一方面的任一种可能的实现方式中任一项的方法或第二方面以及第二方面的任一种可能的实现方式中任一项的方法。

可以理解的是，上述第二方面至第四方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

图1是根据本申请实施例提供的一种场景示意图；

图2a是根据本申请实施例提供的一种用户启动车载情景模式的界面示意图；

图2b是根据本申请实施例提供的一种用户启动哨兵模式的车载情景模式示意图；

图2c是根据本申请实施例提供的一种用户启动哨兵模式的界面示意图；

图2d是根据本申请实施例提供的一种用户自定义车载情景模式的界面示意图；

图2e是根据本申请实施例提供的一种用户设置触发哨兵模式的界面示意图；

图2f是根据本申请实施例提供的一种修改后的哨兵模式的界面示意图；

图2g是根据本申请实施例提供的一种修改后的哨兵模式不符合功能完备性要求的提示界面示意图；

图3是根据本申请实施例提供的一种用户启动车载情景模式的界面示意图；

图4是根据本申请实施例提供的一种在车辆01上更新车载情景模式的系统结构图；

图5是根据本申请实施例提供的一种在手机02上更新车载情景模式的系统结构图；

图6是根据本申请实施例提供的一种车载情景模式自定义的方法流程示意图。

具体实施方式

下面将使用本领域技术人员通常采用的术语来描述说明性实施例的各个方面。

本申请提供了一种车载情景模式的定义方法、车载设备及其介质。下面将使用本领域技术人员通常采用的术语来描述说明性实施例的各个方面。其中，在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A或B，单独存在B这三种情况。另外，在本申请实施的描述中，“多个”是指两个或多于两个。

以下，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性或隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”、“第三”的特征可以明示或隐含地包含一个或更多个该特征。

本申请各实施例提供的一种车载情景模式的定义方法可以应用于手机、平板电脑、车载设备、可穿戴设备、增强现实(augment reality，AR)/虚拟现实(virtual reality，VR)设备、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本、个人数字助理(personal digital assistant，PDA)等终端设备上，本申请实施例对终端设备的具体类型不作任何限制。

目前很多智能汽车提供预置的车载情景模式给用户使用。车载情景模式为用户提供了一种场景化服务。举例来说明，当车辆停放的环境不安全(比如车辆停放位置在用户确定的熟悉的地点之外)，那么用户可以开启哨兵模式。在哨兵模式下，车辆锁闭后，智能汽车会通过前视摄像头、后视摄像头等摄像设备持续监控周围环境，并根据周围发生的不同类型的潜在威胁做出对应级别的警报反映。其中，不同类型的潜在威胁可以是在预置车载情景模式(更具体地是预置哨兵模式)时预先设置好的，本申请对此不作限制。

而当用户需要在车内休息时，可以开启小憩模式。在小憩模式下，车载设备控制智能汽车的座椅自动后靠、下沉，为用户提供舒适的休息姿势。同时车载设备控制车内其他设备进入特定的工作模式，比如车载设备控制车内空调转换为自动循环模式，以保证车内氧气充足，为用户营造良好的休息环境。

但这种方式，为了确保各类型车载情景模式下对应的功能实现的逻辑性和安全性，用户只能使用不能根据自己需求修改(比如增加或者删除)某一车载情景模式下的功能。比如在小憩模式下，为保证车内用户安全，车内空调会进入自动循环模式以保持车内氧气充足，当用户不希望在小憩模式自动开启空调的情况下，用户无法删除小憩模式下启动开启空调的功能。

而且，这类预置的车载情景模式，在投入使用之前，会根据测试用户的反馈反复修改，需要经过一定的研发测试周期，因此无法及时满足各类用户的需求。而且，不同的用户有不同的需求，这些需求之间甚至可能互相矛盾，比如一类用户希望小憩模式下自动开启空调，而另一类用户不希望小憩模式下自动开启空调，因此这类预置的车载情景模式即使经过研发测试也无法满足不同用户的个性化需求。

对此，在一些实现方式中，一些智能汽车支持用户完全自定义的车载情景模式。用户可以通过各类车载应用程序(application，APP)，针对某一类型车载情景模式，根据需求编排、组合自己想要的功能服务。

但这种方式，首先，需要用户清楚车载情景模式的编排流程以及逻辑要求，对于没有相关经验的用户不友好。其次，智能汽车对用户安全、车载情景模式流程的合规性有严格的要求。对于这种完全由用户自定义的车载情景模式，在执行过程中有很大的概率会因不符合安全性、合规性而导致执行失败，而且并不会向用户反馈执行失败的原因。这样用户只有在执行修改以后的车载情景模式后，才知道修改后的车载情景模式到底能否执行成功，并且在车载情景模式执行失败的情况下，用户也不清楚执行失败到底是因为修改后的车载情景模式不符合安全性、合规性的要求，还是修改后的车载情景模式对应的代码有误。影响用户体验。

为了解决上述技术问题，本申请提供了一种车载情景模式的定义方法。

本申请的方法，为用户提供了半预置的车载情景模式，支持用户根据需求修改半预置的车载情景模式的功能(比如增加或删除功能)。并且，在用户修改功能后，车载设备会对用户修改后的车载情景模式进行有效性检测，包括对修改后的车载情景模式的完备性检测、互斥操作检测等等。在这些检测都通过后，用户才可以使用修改后的车载情景模式，或者说，修改后的车载情景模式才可以生效并能够被执行。其中，对修改后的车载情景模式进行有效性检测的具体方法将在下文进行介绍。

并且，在检测过程中，车载设备会向用户反馈修改后车载情景模式不能生效的原因，以及指导用户应该如何修改，以避免车载情景模式在执行过程中失败，提高用户体验。

图1根据本申请实施例示出了一种车载情景模式定义方法的适用场景。

如图1所示，包括智能汽车01(下称车辆01)，智能手机02(下称手机02)。车辆01与手机02能够进行通信。更具体地，车辆01上的车载设备与手机02之间通过包括蓝牙、无线网络等无线通信方式或者有线通信方式实现通信连接。

在一些实现方式中，车辆01包括屏幕A，用户可以通过屏幕A提供的人机交互界面，选择开启需要的车载情景模式。例如，图2a至图2c示出了用户通过屏幕A选择开启车载情景模式的对应的界面变化示意图。

如图2a所示，屏幕A显示界面A00，该界面A00包括广播电台应用A1、车载应用A2、蓝牙应用A3、电话应用A4、导航应用A5、语音识别应用A6等应用。在一些实现方式中，用户点击车载应用A2对应的图标，屏幕A显示如图2b所示的界面A10，该界面显示车辆01可支持的车载情景模式，包括但不限于哨兵模式A21、小憩模式A22，儿童遗落提醒模式、娱乐模式、洗车模式等等，本申请对此不作限制。其中，哨兵模式A21和小憩模式A22可参考前文相关描述。洗车模式指的是用户将车辆送洗过程中，如果开启洗车模式，车辆会自动关闭充电接口、关闭车窗、雨刮器、后备箱，并且同时哨兵模式也会自动开启，这样可以避免在洗车过程中对车辆造成损坏。儿童遗落提醒模式指的是儿童单独在车内时，默认开启空调保温，同时关闭车窗关闭充电接口，以免儿童翻越车窗。

用户可根据需要选择开启相应的车载情景模式，比如用户不确定停车位置是否安全可靠，用户可以开启哨兵模式。例如，如图2b所示，用户可以从界面A10选定哨兵模式A21，然后在如图2c所示的界面A30，通过控件A311开启哨兵模式。又比如用户想要在车内休息，那么用户可以开启小憩模式，再比如用户送车清洗的过程中，用户可以开启洗车模式，等等，本申请对此不作限制。其中，用户开启小憩模式或开启洗车模式的过程与开启哨兵模式的过程一致，本申请对此不作限制。

在一些实现方式中，用户可以根据需求修改选定的车载情景模式的功能。例如，继续以哨兵模式为例，用户可以在图2c所示的界面A30，通过控件A32进入自定义模式，以修改哨兵模式的各功能。例如，图2d所示，用户可以通过点击控件A401选择修改哨兵模式的触发条件，通过点击控件A402选择修改异常报警灯光模式，通过点击控件A403选择修改异常报警声音模式以及通过点击控件A404选择是否开启提醒行人的功能。

进一步地，假设用户希望修改哨兵模式的触发条件，那么如图2e所示的界面A50，用户可以通过点击控件A501选择开启地理围栏自动触发哨兵模式的功能。在一些实现方式中，用户可以通过点击控件A502添加哨兵模式对应的位置黑名单。其中，用于触发哨兵模式的地理围栏可以由用户根据需求自行设置，也可以由用户通过添加位置黑名单或者白名单的方式设置，本申请对此不作任何限制。

可以理解，在一些实现方式中，在用户完成车载情景模式的修改后，车辆01可以控制屏幕A显示确认界面，以便用户确认完成车载情景模式的修改。本申请对此不作限制。

在一些实现方式中，当用户修改的车载情景模式能够被使用时，可以在相应的车载情景模式的图标上显示提示标志，以提醒用户修改的车载情景模式可以被使用。例如，继续以哨兵模式为例，当用户修改的哨兵模式可以被使用时，如图2f所示，可以在哨兵模式对应的图标右上角显示提示标志P，以提示用户修改的车载情景模式可以被使用。在另一些实现方式中，提示标志P可以显示在哨兵模式对应的图标的任意位置，本申请对此不作限制。

在另一些实现方式中，当用户修改的车载情景模式不能被使用时，也即用户修改后的车载情景模式未通过上述有效性检测，为了提高用户体验，车辆01可以显示用户修改后的车载情景模式未通过上述有效性检测的原因。

例如，假设用户修改的哨兵模式未通过上述有效性检测，那么如图2g所示，车辆01的屏幕A显示界面A60，并显示“车主您好，您的修改操作不符合功能完备性要求，请您重新修改”。在一些实现方式中，用户可以点击控件A602查看详情，以了解更详细具体地未通过有效性检测的原因。本申请对此不作限制。

在一些实现方式中，车辆01还可以包括其他更多的屏幕，比如屏幕B，用户可以通过屏幕B提供的人机交互界面，选择开启或者修改车载情景模式，其中，用户通过屏幕B开启或修改车载情景模式的过程中屏幕B界面变化与上图2a至图2g一致，不再赘述。

在另一些实现方式中，用户也可以通过手机02上安装的车载APP，选择需要开启的车载情景模式，手机02检测到用户开启车载情景模式的启动指令后，控制车载设备开启对应的车载情景模式，或者向车载设备发送该启动指令后，由车载设备根据该启动指令开启对应的车载情景模式，本申请对此不作限制。例如，如图3所示，手机02桌面020显示车载应用0101、电话应用0102、导航应用0103等应用。与用户通过车辆01屏幕A显示的车载应用A2开启车载情景模式类似，用户可通过手机02桌面020的车载应用0101开启需要的车载情景模式，此处不再赘述。

图4根据本申请实现方式示出了一种定义车载情景模式的系统结构图。如图4所示，该系统包括车辆01，手机02，云服务器03。

其中，车辆01包括显示模块011，错误反馈模块012，驾驶舱域控制器(cockpitdomain controller，CDC)01A，远程信息处理器(telematics box，T-Box)010。具体地，在一些实现方式中，显示模块011提供用户界面，例如图2a至图2c所示的界面A00、界面A10、界面A20等界面，以便用户通过用户界面与车辆01实现交互。例如，用户通过图2a所示的界面A00启动车载应用A2。又例如，用户通过图2b所示的界面A10开启哨兵模式A21。

在另一些实现方式中，显示模块011在用户修改的车载情景模式检测失败后，根据错误反馈模块012反馈，为用户显示如图2g所示的修改的车载情景模式检测失败的原因。在一些实现方式中，显示模块011在显示前述失败原因的同时，还可以显示对应的修改方式。本申请对此不作限制。

CDC01A包括第一存储模块013，第二存储模块014，检测模块015以及更新模块016。其中，第一存储模块013用于存储预置的车载情景模式的信息(下称预置数据)，比如预置的车载情景模式的类型，以及各类型车载情景模式下对应的功能。示例性地，本申请中涉及的部分车载情景模式的类型以及各类型车载情景模式下的部分功能可如下表1所示：

表1部分车载情景模式的类型以及各类型车载情景模式下的部分功能

也即，车载情景模式包括至少一种情景模式，每个情景模式表示车辆中多个部件的特定工作方式的组合。例如上表1所示的，在哨兵模式的情景模式下，情景模式对应的车辆部件至少包括报警灯和报警音频发声部，工作方式是报警灯闪烁，和报警音频发生部发出报警语音。在洗车模式下，该情景模式对应的车辆部件至少包括车窗、车内充电接口，对应的工作方式是车窗关闭，车内充电接口自动断电。在娱乐模式下，驻车时座椅根据用户体位自动调节、开启车内环绕音效、支持外界娱乐设备，例如游戏手柄等等。

第二存储模块014用于存储预置数据以及用户修改数据。其中，用户修改数据包括用户修改操作对应的车载情景模式的类型以及该用户修改操作针对的该类型车载情景模式下的功能。比如，用户对哨兵模式的触发条件进行修改，那么用户修改数据包括哨兵模式以及哨兵模式下用户修改的哨兵模式的触发条件(比如地理围栏自动触发哨兵模式功能)。

检测模块015则用于对用户修改后的车载情景模式是否有效进行检测。在一些实现方式中，检测模块015对用户修改后的车载情景模式进行有效性检测的项目包括对修改后的车载情景模式进行完备性检测以及互斥操作检测。其中，完备性测试指的是对用户修改后的车载情景模式功能的完整性检测，确定修改后的车载情景模式的功能是否仍符合模式设计的逻辑等。比如，对于哨兵模式而言，车辆01停放位置的检测功能不可以删除，如果用户出于降低功耗的考虑，删除车辆01停放位置的检测功能，那么修改后的哨兵模式就是不符合完备性要求的，也即不能通过有效性检测。再比如，哨兵模式一般具有多种类型的风险检测，比如不明人员靠近风险检测、车门/后备箱开启风险检测、座舱内动静风险检测、车辆倾斜风险检测，而就哨兵模式而言，不明人员靠近风险检测与车门/后备箱开启风险检测二者必须要保留一个，才能确定是不明人员开启车门/后备箱，因此当用户出于其他目的诸如降低功耗的考虑，将不明人员靠近风险检测以及车门/后备箱开启风险检测的功能均删除后，那么修改后的哨兵模式就是不符合完备性要求的，也即不能通过有效性检测。

互斥操作检测指的是针对车辆行驶规范、用户人身安全等，从安全性角度进行的检测。比如，对于儿童遗忘提醒模式，出于安全考虑，用户不能删除禁用语音功能、屏幕点击，防止儿童误触造成危险。

可以理解，每一种类型的车载情景模式都有对应的有效性检测条件。该有效性检测条件可以由研发人员根据各类型车载情景模式对应的功能进行设置，本申请对此不作任何限制。对应地，在一些实现方式中，预置数据可以包括各类车载情景模式对应的有效性检测条件。

在一些实现方式中，检测模块015还可以对修改后的车载情景模式进行场景测试。具体地，检测模块015可以预置多种常规测试场景，然后在各常规测试场景下对修改后的车载情景模式进行有效性检测。例如，对于儿童遗落提醒模式，它的常规测试场景可以是，模拟不同电量下，开启用户选择的服务(例如开启空调、中控屏播放儿童读物)后，车辆01所能保持运行的时长，以便于检测模块015能够根据不同电量对应的常规测试场景下车辆01所能保持的运行的时长，确定更合理的开启儿童遗落提醒模式时对应的最低电量阈值，以防止在最低电量阈值下开启儿童遗落提醒模式后，出现车辆01电量不足引发的安全事故。

可以理解，在一些实现方式中，检测模块015可以仅对修改后的车载情景模式进行完备性检测以及互斥操作检测，也可以再对修改后的车载情景模式进行场景测试，并且测试顺序不作限制，也即检测模块015可以相对修改后的车载情景模式进行场景测试，再对其进行完备性测试以及互斥操作检测，也可以相对修改后的车载情景模式进行完备性测试以及互斥操作检测，再对修改后的车载情景模式进行场景测试，本申请对此不作任何限制。

在一些实现方式中，检测模块015完成对修改后的车载情景模式的有效性测试，并且修改车载情景模式未通过有效性测试的情况下，检测模块015将车载情景模式未通过有效性测试的原因的发送至错误反馈模块012，由错误反馈模块012发送至显示模块011，显示给用户。

在一些实现方式中，检测模块015完成对修改后的车载情景模式的有效性测试，并且修改车载情景模式通过有效性测试的情况下，则由更新模块016将原来车载情景模式更新为修改后的车载情景模式。

并且，在一些实现方式中，由于用户可能通过手机02修改车载情景模式，所以为了保证用户通过手机02或者车辆010能达到同样的修改效果，手机02提供的车载情景模式与车辆010提供的车载情景模式，有必要保持一致。也即，如果车辆010上的车载情景模式没有更新，那么手机02提供的同类型的车载情景模式也应该没有更新，如果车辆010上的车载情景模式更新，那么手机02提供的同类型的车载情景模式也应该是更新过的。反之亦然。其中，车载情景模式没有更新的情况包括用户未对其做修改，或者用户修改过该车载情景模式，但是修改后的车载情景模式未通过检测模块015的有效性检测。

在一些实现方式中，车辆01与手机02之间的通过T-BOX 010以及云服务器03进行数据的传送以及更新。

在一些实现方式中，T-B0X 010也可以叫车辆盒子，它的主要功能是当用户通过手机02的车载应用A2发送控制指令后，车辆01会发出监控请求指令到T-BOX 010。T-BOX 010在接收该监控请求指令后，通过控制器局域网络(controller area network，CAN)总线，发送与该监控请求指令相应的控制报文给车辆01中相应的部件，实现对车辆的控制，并将控制结果反馈到手机02的车载应用A2上。通过这种方式，用户可以通过手机02实现远程启动车灯、打开空调、调整座椅、打开发动机等等。

在一些实现方式中，云服务器03用于获取并存储车辆01中车载情景模式对应的数据，包括预置的车载情景模式的数据以及用户修改后通过有效性检测的车载情景模式的数据，以便于手机02更新模块021通过这些数据更新车载情景模式，与车辆010车载情景模式保持一致。

图5根据本申请的实现方式示出了另一种定义车载情景模式的系统图。其中，图5与图4的区别之处在于，基于图5所示的系统图，用户可以通过手机02修改车载情景模式。下面对此展开介绍，与图4相同之处，以下不再赘述。

如图5所示，该系统包括手机02、车辆01，云服务器03。其中，手机02包括显示模块022、错误反馈模块023以及更新模块021。显示模块022用于向用户提供如图3所示的用户界面020，以使用户能够通过车载应用0101选择并修改车载情景模式。错误反馈模块023的功能与作用与图4中错误反馈模块012相同，更新模块021与图4中更新模块021的功能和作用相同，车辆010中各模块的功能和作用与图4中车辆010中各模块的功能和作用相同，不再赘述。

在一些实现方式中，用户通过手机02的显示模块022提供的用户界面020选择启动车载应用0101，并且选择要修改的车载情景模式后，手机02通过云服务器03、T-B0X 010将修改指令发送至车辆010中的CDC 01A，CDC 01A将用户修改数据存储在第二存储模块014，然后通过检测模块015对修改后的车载情景模式进行有效性检测，如果检测没有通过，那么同样由CDC 01通过T-B0X 010将失败原因同步至错误反馈模块023，并由错误反馈模块023发送至显示模块022显示。如果检测通过，那么还是由CDC 01通过T-B0X 010将修改后的车载情景模式同步更新至更新模块021，使手机02上的车载情景模式与车辆010的车载情景模式保持一致。

可以理解，除了用户修改车载情景模式以外，车载情景模式对应的车载应用(例如车载应用A2)也会自动更新车载情景模式，或者说自动更新上述预置数据。例如，在交通道路法规等更新的时候，车载应用A2需要更新上述各类型车载情景模式对应的有效性检测条件，尤其是需要更新有效性检测条件中的互斥操作检测条件，以免出现由于用户修改功能，而出现不合规的情况。比如，对于娱乐模式，用户如果增加了座椅摇摆功能，那么同时也许要增加车内是否有儿童的检测功能，否则可能会因为儿童出现在车内，但是儿童乘坐方式不符合交通道路法规规定的情况。再例如，研发人员根据数据统计需要更新一些车载情景模式下的音效数据库、灯光模式数据库等等，那么对应的车载应用A2需要更新涉及到音效、灯光模式等功能的车载情景模式。

为了避免车载应用自身系统或版本升级而覆盖用户修改的车载情景模式，在本申请的一些实现方式中，可以将用户修改数据以及预置数据(包括未经过系统或版本更新的车载情景模式对应的数据或经过系统或版本更新的车载情景模式对应的数据)分开存储。然后当车辆01检测到车载应用自身系统或版本更新的情况下，先利用更新的版本数据更新原有的预置数据，得到更新版本对应的预置数据，然后再利用用户修改数据修改更新版本对应的预置数据，以得到用户修改后的车载情景模式对应的数据。也即是，车辆01检测到用户修改指令以及车载应用A2系统更新的情况下，先对车载应用A2的系统进行更新，然后根据用户修改指令，修改更新后的车载情景模式，以得到用户修改后的车载情景模式。

通过这种方法，确保用户修改操作是针对系统或版本更新后的车载情景模式进行的，以确保用户修改数据不被版本更新数据覆盖。

下面结合图6介绍本申请车载情景模式的定义方法。为便于说明，以车辆01实现本请方案为例。具体地，如图6所示，该方法包括：

601，检测到用户针对于目标车载情景模式的修改指令。

在一些实现方式中，用户选定目标车载情景模式后，即可对目标车载情景模式进行修改。在一些实现方式中，当车辆01检测到用户作出如图2b至图2d所示的操作后，即确定检测到用户针对于目标车载情景模式的修改指令。

可以理解，用户操作包括但不限于如图2b至2d所示的点击操作，还可以用其他可以触发对应功能的操作，例如用户输入预设语音指令，等等，本申请对此不作限制。

在一些实现方式中，目标车载情景模式包括但不限于上文提及的哨兵模式、儿童遗落提醒模式、娱乐模式、小憩模式、洗车模式。

602，车辆01根据修改指令，修改目标车载情景模式，得到修改后的车载情景模式。

例如，对于小憩模式，用户增加或者删除与车辆01联动的设备，或者修改小憩模式下音乐种类、音乐音量、音乐音效，增加小憩模式下香薰浓度、座椅角度，自动按摩的方式，等等，可以得到修改后的小憩模式。其中，与车辆01联动的设备包括用户手机02、蓝牙耳机、智能按摩仪，等等，本申请对此不作限制。

又例如，对于儿童遗落提醒模式，用户可以将空调保温功能修改为空调内循环或外循环功能，得到修改后的儿童遗落提醒模式。或者在儿童遗落提醒模式下，用户可以增加车窗可以自动开启预设距离缝隙的功能，得到修改后的儿童遗落提醒模式。其中，预设距离为经验值或实验值，本申请对此不作限制。又或者，在儿童遗漏提醒模式，用户可以增加屏幕A自动播放选定动画或音乐专辑的功能，得到修改后的儿童遗落提醒模式。本申请对此不作限制。

还例如，对于娱乐模式，用户可以修改与车辆01内的联动设备，比如，用户可以增加座椅、空调、音效、灯光等设备的联动，得到修改后的娱乐模式。

再例如，对于洗车模式，用户可以修改调整车辆01的挡位、下电、锁车等的组合方式，得到针对不同洗车场景下不同的洗车模式。其中，锁车指的是车辆01下电后或熄火的同时将车辆01的全部电源切断。对应地，不锁车指的是车辆01下电后或熄火后，仍然保持车辆01中防盗警报器、报警指示灯等设备继续工作。因此，在清洗车身外部时，为避免损坏车辆01，还需要同时对车辆01承担的风险进行监测，以便提醒用户车辆01可能遭受的风险。所以，用户可以将停车档、下电以及不锁车作为清洗车身外部时的组合，以保证在清洗车身外部时，车辆01中的车辆01风险监测相关的设备能够继续工作，以监测车辆01的风险。

603，车辆01对修改后的车载情景模式进行有效性检测，并根据检测结果决定是否更新目标车载情景模式。若修改后的车载情景模式的有效性检测通过，那么执行604，车辆01将目标车载情景模式更新为修改后的车载情景模式。若修改后的车载情景模式的有效性检测没有通过，那么执行605，不更新目标车载情景模式，并且显示有效性检测不通过的原因。

可以理解，每一类型的车载情景模式都有对应的有效性检测条件，车辆01在对修改后的车载情景模式进行有效性检测时，根据该车载情景模式对应的有效性检测条件，对该类型车载情景模式是否有效进行检测。

例如，如果车辆01确定该车载情景模式为哨兵模式，车辆01利用与哨兵模式对应的有效性检测条件对修改后的哨兵模式进行有效性检测。其中，哨兵模式的有效性检测条件可由研发人员根据哨兵模式支持的功能预先设置。并且可以理解，哨兵模式支持的功能包括预置的哨兵模式对应的功能以及用户修改的功能(比如用户增加的功能)。

示例性地，对于哨兵模式，可以理解，关于车辆01停放位置的地点检测功能是不可以删除的，同时要保证车辆01有足够的电量返程，因此用户修改启动哨兵模式的触发电量值不可以低于第一阈值。也即是说，当用户新增的哨兵模式的启动条件中的触发电量值低于第一阈值时，车辆01确定用户修改的哨兵模式不满足完备性条件，不能生效。其中，第一阈值为经验值或实验值，例如可以是20％到30％。

示例性地，对于小憩模式，为了在使用中途发生电路耗尽的情况，在启动小憩模式时对应的车辆01的电量检测需要与用户设置小憩模式的时长进行关联，也即用户设置小憩模式的时长越长，那么用户启动小憩模式时对应的车辆01的电量应该越大，以保证小憩模式下电量始终是充足的。那么如果用户自行解除小憩模式下车辆01的电量检测与小憩模式时长之间的关联，车辆01确定用户修改后的小憩模式不满足完备性条件，不能生效。再例如，为了保证用户休息质量，小憩模式下车辆01会自动开启免打扰功能，但是同时为了提高用户体验，小憩模式也需提供闹钟或者计时功能，以避免发生用户休息时间过长错误重要会议安排的情况，因此，小憩模式下免打扰功能和计时功能也需要同时存在。如果用户删除免打扰功能和/或计时功能，车辆01确定用户修改后的小憩模式不满足完备性条件，也即不能生效。其中，免打扰功能包括但不限于车辆01不提示用户任何车辆01或与车辆01关联的其他电子设备的信息。

示例性地，对于儿童遗落提醒模式，出于安全性的考虑，车辆01与通风相关的服务至少需要保留一个，因此当用户将儿童遗落提醒模式下的通风相关的服务均删掉时，车辆01确定用户修改后的儿童遗落提醒模式不满足完备性条件，不能生效。其中，在一些实现方式中，通风相关的服务包括空调内循环、外循环等等服务，本申请对此不作限制。

在一些实现方式中，对于儿童遗落提醒模式，出于降低车辆01电池功耗的考虑，用户自定义的音量的上限值也不能超过音量阈值。也即是说，当用户修改儿童遗落提醒模式下，关于儿童遗落提醒的相关的音效的音量时，如果用户修改该音效的音量上限值超过音量阈值，车辆01确定用户修改的儿童遗落提醒模式不满足完备性条件，不能生效。

示例性地，对于洗车模式，为了避免对车辆01造成损耗，在洗车时，车辆01的车窗、充电口、空调内循环、外循环等等均需关闭。因此，洗车模式的车窗是否关闭检测、充电口是否关闭检测、空调是否关闭检测，等检测功能不可以被删除。也就是说，当用户修改洗车模式下的上述任一种检测功能时，车辆01确定用户修改的洗车模式不满足完备性条件，不能生效。

类似地，车辆01利用各类型车载情景模式对应的预设互斥操作检测条件，对车载情景模式的有效性检测检测。其中，各类型车载情景模式对应的预设互斥操作检测条件也由研发人员根据需求，根据各类型车载情景模式对应的沟通进行设置，本申请对此不作限制。

示例性地，对于儿童遗落提醒模式，出于安全考虑，用户不能删除语音禁用功能以及屏幕触控禁用功能，以免儿童误触发造成危险，并且禁止在儿童遗落提醒模式下的后台应用更新升级，以免在更新过程中的部分服务与通风服务冲突造成通风服务无法使用，导致汽车01内氧气不足。也就是说，当用户在修改儿童遗落提醒模式时，删除语音禁用功能、或者屏幕触控禁用功能，车辆01确定用户修改后的儿童遗落提醒模式不满足互斥操作检测条件，不能生效。

示例性地，对于娱乐模式，同样出于安全考虑，用户增加座椅摇摆功能的情况下，需要检测当前娱乐模式下是否有车内有无儿童的检测以及行车是否安全的检测。也就是说，当用户修改娱乐模式，增加座椅摇摆功能的情况下，车辆01如果没有检测到修改后的娱乐模式有车内有无儿童的检测以及行车是否安全的检测，车辆01确定用户修改后的娱乐模式不满足互斥操作检测条件，不能生效。

604，车辆01确定修改后的车载情景模式的有效性检测通过，车辆01将目标车载情景模式更新为修改后的车载情景模式。

其中，具体地更新方式可参考图4、图6的相关描述，此处不再赘述。

605，车辆01确定修改后的车载情景模式的有效性检测未通过，车辆01不更新目标车载情景模式，显示有效性检测不通过的原因。例如图2g所示，当用户修改哨兵模式不符合完备性条件的情况下，显示提示信息“车主您好，您的修改曹邹不符合功能完备性要求，请您重新修改”。

通过上述方法，用户即可根据自己的需求修改预置的车载情景模式，并且由于会在执行该车载情景模式之前，便对其进行有效性检测，并且会向用户反馈有效性检测未通过的原因，以使用户能够进行针对性的修改，避免在执行过程中出现修改后的车载情景模式无法执行的情况，提供了用户体验。

本申请实施例还提供了一种电子设备，该电子设备包括：至少一个处理器、存储器以及存储在所述存储器中并可在所述至少一个处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述任意各个方法实施例中的步骤。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。

本申请实施例提供了一种计算机程序产品，当计算机程序产品在移动终端上运行时，使得移动终端执行时实现可实现上述各个方法实施例中的步骤。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质至少可以包括：能够将计算机程序代码携带到拍照装置/终端设备的任何实体或装置、记录介质、计算机存储器、只读存储器(read-only memory，ROM)、随机存取存储器(random accessmemory，RAM)、电载波信号、电信信号以及软件分发介质。例如U盘、移动硬盘、磁碟或者光盘等。在某些司法管辖区，根据立法和专利实践，计算机可读介质不可以是电载波信号和电信信号。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

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

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

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

以上描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本申请说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当……时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

以上所述实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (14)

1.一种车载情景模式的定义方法，应用于第一电子设备，其特征在于，包括：

检测到用户针对于目标车载情景模式的修改指令；

根据修改指令修改所述目标车载情景模式，得到修改后的车载情景模式；

对修改后的车载情景模式进行有效性检测，并根据检测结果决定是否更新所述目标车载情景模式，其中，

对应于修改后的车载情景模式通过所述第一电子设备的有效性检测，将所述目标车载情景模式更新为修改后的车载情景模式。

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

对应于修改后的车载情景模式未通过所述第一电子设备的有效性检测，不更新所述目标车载情景模式。

3.根据权利要求1所述的方法，其特征在于，所述对修改后的车载情景模式进行有效性检测，包括：

确定与修改后的车载情景模式对应的有效性检测条件，

根据所述对应的有效性检测条件，对所述修改后的车载情景模式进行有效性检测。

4.根据权利要求1至3中任一项所述的方法，其特征在于，所述有效性检测至少包括对所述修改后的车载情景模式对应的功能进行完备性检测以及互斥操作检测。

5.根据权利要求1至3中任一项所述的方法，所述目标车载情景模式至少包括一种情景模式，每个所述情景模式表示第一电子设备所在车辆中多个设备的特定工作方式的组合。

6.根据权利要求5所述的方法，其特征在于，所述目标车载情景模式至少包括以下任一项情景模式：

小憩模式、儿童遗落提醒模式、洗车模式、娱乐模式或哨兵模式。

7.根据权利要求2至5中任一项所述的方法，其特征在于，所述方法还包括：

在所述第一电子设备显示所述修改后的车载情景模式未通过所述有效性检测的原因。

8.根据权利要求1至7中任一项所述的方法，其特征在于，所述方法还包括：

将所述修改后的车载情景模式发送至第二电子设备，其中，被发送的所述修改后的车载情境模式能够使得所述第二电子设备更新所述第二电子设备上的所述目标车载情景模式。

9.根据权利要求2至7中任一项所述的方法，其特征在于，所述方法还包括：

对应于修改后的车载情景模式未通过所述第一电子设备的有效性检测，不更新所述目标车载情景模式，发送第二信息，所述第二信息用于在第二电子设备上显示所述修改后的车载情景模式未通过所述有效性检测的原因。

10.根据权利要求8或9所述的方法，所述第一电子设备包括车载设备，所述第二电子设备包括智能手机或平板电脑。

11.根据权利要求1所述的方法，其特征在于，所述第一电子设备包括驾驶舱控制器，所述驾驶舱控制器包括检测模块，所述检测模块用于对修改后的车载情景模式进行有效性检测。

12.一种计算机可读介质，其特征在于，所述计算机可读介质上存储有指令，该指令在计算机上执行时使计算机执行权利要求1至11中任一项所述的方法。

13.一种电子设备，其特征在于，所述电子设备包括：

存储器，用于存储由电子设备的一个或多个处理器执行的指令，以及

一个或多个处理器，用于执行所述存储器中存储的指令，使得所述电子设备执行如权利要求1至11中任一项所述的方法。

14.一种计算机程序产品，其特征在于，当计算机程序产品在电子设备上运行时，使得电子设备执行如权利要求1至11中任一项所述的方法。