车辆访问权限控制方法、车机设备及车辆与流程

1.本技术涉及汽车控制技术领域，尤其涉及一种车辆访问权限控制方法、车机设备及车辆。


背景技术：

2.目前，随着互联网软件技术的不断开发，车载终端上可安装的应用程序(application，app)越来越广泛。app在运行过程中，需要调用车载终端的硬件和软件资源，来支撑自身的运行。当app调用车载终端的硬件和软件资源时，通常需要车机设备进行访问权限校验。若有访问权限，则调用资源；若未被授权，则无法调用资源。然而，车载终端app通过这种权限控制策略调用资源，管控效果较差，无法满足用户驾车及信息安全性的需求。


技术实现要素：

3.本技术提供一种车辆访问权限控制方法、车机设备及车辆，解决了目前应用于车辆的权限管控效果较差的问题。
4.为达到上述目的，本技术采用如下技术方案：
5.第一方面，本技术提供一种车辆访问权限控制方法，该方法包括：
6.在接收到第一应用对第一车机信号的访问请求时，检测第一车辆处于预设场景模式，其中，第一应用为第一车辆的车机设备上加载的应用；
7.若第一车机信号在预设场景模式下不支持被访问，则禁止第一应用访问第一车机信号；
8.或者，若第一车机信号在预设场景模式下支持被访问且无需权限校验，则允许第一应用访问第一车机信号；
9.或者，若第一车机信号在预设场景模式下支持被访问且需要权限校验，则对第一应用进行权限校验，并且根据权限校验结果，允许或者禁止第一应用访问第一车机信号。
10.通过上述方案，当app调用车机设备接口以访问车机信号时，首先判断系统目前处于什么场景模式下，然后判断请求访问的车机信号在当前场景模式下是否支持被访问，在不支持访问的情况下禁止访问车机信号；或者在支持被访问的情况下判断是否需要权限校验，进一步地，在无需权限校验时直接访问车机信号，而在需要权限校验时根据校验结果允许或禁止访问车机信号。本技术方案在不同场景下采用的信号权限访问机制不同，实现基于场景模式的车辆权限管控，可提升车辆驾驶安全性及信息安全性。
11.其中，本技术实施例有针对性地区别设置同一信号在不同场景模式下的访问权限，例如对于某一访问信号，在某些场景模式下不支持被访问，而在有些场景模式下可支持被访问(此时可直接访问而无需权限校验，或者在权限校验成功后进行访问)，即不同场景下采用的信号权限访问机制不同，从而实现基于场景模式的车辆权限管控。
12.其中，第一应用可以为系统app，也可以为第三方app。
13.在一些可能实现方式中，所述根据权限校验结果，允许或者禁止第一应用访问第
一车机信号，包括：若权限校验结果指示第一应用有访问权限，则允许第一应用访问第一车机信号；或者，若权限校验结果指示第一应用无访问权限，则禁止第一应用访问第一车机信号。
14.在一些可能实现方式中，在允许或者禁止第一应用访问第一车机信号之前，所述方法还包括：确定第一应用请求访问第一车机信号对应的目标访问方式，该目标访问方式为以写入方式访问或者以读取方式访问。
15.在此情况下，所述允许或者禁止第一应用访问第一车机信号，包括：允许或者禁止第一应用按照目标访问方式访问第一车机信号。
16.在一些可能实现方式中，所述对第一应用进行权限校验，包括：
17.输出第一提示信息，用于提示是否同意第一应用对第一车机信号的访问权限；
18.根据用户对第一提示信息的响应输入，得到权限校验结果；
19.其中，上述权限校验结果指示第一应用具有访问第一车机信号的权限，或者权限校验结果指示第一应用不具有访问第一车机信号的权限。
20.在一些可能实现方式中，上述第一提示信息包括至少一个选项，该至少一个选项包括以下至少一项：拒绝授予对第一车机信号访问的权限、同意授予对第一车机信号访问的权限、同意授予对同类信号访问的权限、查看同类信号对应的访问权限信息，该同类信号为与第一车机信号属于相同访问控制等级的信号。
21.在一些可能实现方式中，所述对第一应用进行权限校验，包括：根据预先存储的与第一应用对应的访问权限信息，确定第一应用是否具有访问第一车机信号的权限。
22.在一些可能实现方式中，所述根据预先存储的与第一应用对应的访问权限信息，确定第一应用是否具有访问第一车机信号的权限，包括：
23.若第一应用对应的访问权限信息指示第一应用允许访问第一车机信号，则确定第一应用具有访问第一车机信号的权限；
24.或者，若第一应用对应的访问权限信息指示第一应用禁止访问第一车机信号，则确定第一应用不具有访问第一车机信号的权限。
25.在一些可能实现方式中，在根据预先存储的访问权限信息，确定第一应用是否具有访问第一车机信号的权限之前，所述方法还包括：
26.当检测到车机设备初次安装第一应用并运行第一应用时，输出第二提示信息，用于提示是否同意第一应用的访问权限；根据用户对第二提示信息的响应输入，存储与第一应用对应的访问权限信息；
27.或者，在车机设备安装有第一应用的情况下，根据用户在权限管理界面中对第一应用的访问权限进行的设置操作，存储与第一应用对应的访问权限信息。
28.在一些可能实现方式中，在根据第一车机信号在预设场景模式下的访问权限，允许或者禁止第一应用访问第一车机信号之前，所述方法还包括：确定第一车机信号对应的访问控制等级；根据第一车机信号对应的访问控制等级和预先存储的基于场景的权限信息，确定第一车机信号在预设场景模式下的访问权限；其中，该基于场景的权限信息用于指示访问控制等级在各种场景模式下的访问权限。
29.需要说明的是，上述基于场景的权限信息可以由系统厂商设置或更新，也可以由车厂设置或更新。例如，车厂可以基于系统厂商提供的安全子系统，新增车机信号名及其权
限定义，还可以修改已有车机信号权限信息。
30.在一些可能实现方式中，所述允许第一应用访问第一车机信号，包括：向第一应用发送第一车机信号；或者，接收第一应用发送的第一车机信号，并根据第一车机信号更新与第一车机信号对应的车机功能设置信息。
31.在一些可能实现方式中，所述检测第一车辆处于预设场景模式，包括：采集第一车辆的目标参数，该目标参数包括以下至少一项：车辆故障检测结果，行驶速度，位于驾驶座上的驾驶人员的人脸图像；并根据目标参数，确定所述第一车辆处于预设场景模式。
32.其中，若目标参数满足预设场景判定参数，则将与预设场景判定参数对应的场景模式确定为预设场景模式。例如，上述预设场景模式可以为以下任一项：紧急模式、驾驶模式、非驾驶模式、访客模式。
33.在一些可能实现方式中，所述根据目标参数，确定第一车辆处于预设场景模式，包括：
34.若第一车辆的车辆故障检测结果指示车辆发生故障，则确定第一车辆处于紧急模式；
35.或者，若第一车辆的行驶速度大于或等于预设速度阈值，则确定第一车辆处于驾驶模式；
36.或者，若第一车辆的行驶速度小于预设速度阈值，则确定第一车辆处于非驾驶模式；
37.或者，若位于第一车辆的驾驶座上的驾驶人员的人脸图像与预设人脸图像的匹配度小于匹配度阈值，则确定第一车辆处于访客模式。
38.在一些可能实现方式中，所述根据目标参数，确定第一车辆处于预设场景模式，包括：若目标参数符合至少两种场景模式，则将至少两种场景模式中优先级较高的场景模式确定为第一车辆的主场景模式，以及将至少两种场景模式中优先级较低的场景模式确定为第一车辆的次场景模式；其中，主场景模式对应的信号访问优先级高于次场景模式对应的信号访问优先级。
39.示例性地，至少两种场景模式包括优先级从高到低排列的紧急模式、驾驶模式、访客模式中的至少两项，或者优先级从高到低排列的紧急模式、访客模式、非驾驶模式中的至少两项。
40.第二方面，本技术提供一种车辆访问权限控制的装置，该装置包括用于执行上述第一方面中的方法的单元。该装置可对应于执行上述第一方面中描述的方法，该装置中的单元的相关描述请参照上述第一方面的描述，为了简洁，在此不再赘述。
41.其中，上述第一方面描述的方法可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块或单元。例如，处理模块或单元、显示模块或单元等。
42.第三方面，本技术提供一种车机设备，该车机设备包括处理器，处理器与存储器耦合，存储器用于存储计算机程序或指令，处理器用于执行存储器存储的计算机程序或指令，使得第一方面中的方法被执行。
43.例如，处理器用于执行存储器存储的计算机程序或指令，使得该车机设备执行第一方面中的方法。
44.第四方面，本技术提供一种车辆，该车辆包括第三方面中的车机设备。
45.第五方面，本技术提供一种计算机可读存储介质，其上存储有用于实现第一方面中的方法的计算机程序(也可称为指令或代码)。例如，该计算机程序被计算机执行时，使得该计算机可以执行第一方面中的方法。
46.第六方面，本技术提供一种芯片，包括处理器。处理器用于读取并执行存储器中存储的计算机程序，以执行第一方面及其任意可能的实现方式中的方法。可选地，所述芯片还包括存储器，存储器与处理器通过电路或电线连接。
47.第七方面，本技术提供一种芯片系统，包括处理器。处理器用于读取并执行存储器中存储的计算机程序，以执行第一方面及其任意可能的实现方式中的方法。可选地，所述芯片系统还包括存储器，存储器与处理器通过电路或电线连接。
48.第八方面，本技术提供一种计算机程序产品，所述计算机程序产品包括计算机程序(也可称为指令或代码)，所述计算机程序被计算机执行时使得所述计算机实现第一方面中的方法。
49.可以理解的是，上述第二方面至第八方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。
附图说明
50.图1为本技术实施例提供的车辆访问权限控制方法的流程示意图之一；
51.图2为本技术实施例提供的车辆访问权限控制方法应用的车机设备显示界面的示意图；
52.图3为本技术实施例提供的车辆访问权限控制方法的流程示意图之二；
53.图4为本技术实施例提供的车辆访问权限控制方法的流程示意图之三；
54.图5为本技术实施例提供的车辆访问权限控制方法中操作系统厂商与oem厂商交互定义权限管控策略的示意图；
55.图6为本技术实施例提供的车辆访问权限控制装置的结构示意图；
56.图7为本技术实施例提供的车机设备的结构示意图。
具体实施方式
57.为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
58.本文中术语“和/或”，是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。本文中符号“/”表示关联对象是或者的关系，例如a/b表示a或者b。
59.本文中的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一提示信息和第二提示信息等是用于区别不同的提示信息，而不是用于描述提示信息的特定顺序。
60.在本技术实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本
申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
61.在本技术实施例的描述中，除非另有说明，“多个”的含义是指两个或者两个以上，例如，多个处理单元是指两个或者两个以上的处理单元等；多个元件是指两个或者两个以上的元件等。
62.随着传统封闭式车辆向智慧化车辆演进，车辆应用生态将会逐渐丰富，更加开放，随之带来的车辆安全问题日渐突出。例如，在车辆行驶时，应用有可能触发诸如车门开启等操作，会严重威胁驾驶安全；或者应用可能会访问到车辆隐私信息，导致车辆隐私安全没有保障。因此，本技术实施例要解决的技术问题是如何有效管控车机信号，保障车辆驾驶安全和隐私安全。
63.本技术实施例提供一种车辆权限控制方法、车机设备以及包括车机设备的车辆，该车辆权限控制方法可以应用于该车机设备。通过该车辆权限控制方法，当app调用车机设备接口以访问车机信号时，首先判断系统目前处于什么场景模式下，然后判断请求访问的车机信号在当前场景模式下是否支持被访问，在不支持访问的情况下禁止访问车机信号，而在支持被访问的情况下判断是否需要权限校验；在无需权限校验时直接访问车机信号，在需要权限校验时根据校验结果允许或禁止访问车机信号。本技术方案在不同场景下采用的信号权限访问机制不同，实现基于场景模式的车辆权限管控，可提升车辆驾驶安全性及信息安全性。
64.由于车辆设备是一种特殊的设备，在不同模式下同一信号的管控不同，如车门在非驾驶模式下，认为可以被三方应用打开/关闭，但当进入到驾驶模式时将不允许任何app打开车门，避免驾驶危险隐患。因此对车辆做到根据不同模式实现不同管控，将显得尤其重要。
65.本技术实施例提供的车辆权限控制方法的执行主体可以为上述的车机设备，也可以为该车机设备中能够实现该车辆权限控制方法的功能模块和/或功能实体，具体的可以根据实际使用需求确定，本技术实施例不作限定。下面以车机设备为例，结合附图对本技术实施例提供的车辆权限控制方法进行示例性的说明。
66.图1是本技术实施例提供的车辆权限控制方法的流程示意图。参照图1所示，该方法100包括下述的s110-s160。
67.s110，车机设备在接收到第一应用对第一车机信号的访问请求时，检测第一车辆处于预设场景模式。
68.其中，上述第一应用为第一车辆的车机设备上加载的应用。可选地，该第一应用可以为车机设备上预置的系统应用，也可以为车机设备上安装的第三方应用，具体可以根据实际使用需求确定，本技术实施例不作限定。
69.可选的，在本技术实施例中，第一车机信号可以指车辆控制信号，例如用于车辆开锁、调节车内温度、调节驾驶座椅、调节车窗开关、调节天窗开关、开启后备箱、发动汽车、降低车速、刹车、开启远光灯的控制信号；也可以指辅助驾驶信号，例如用于导航播报、紧急制动辅助、车道变道辅助、车道保持辅助、自动泊车、车辆定位或者其他自动驾驶辅助信号；还可以是驾驶安全相关的其他信号，例如用于紧急救援、故障检修提示、远程控制、蓝牙电话
等信号。
70.需要说明的是，以上示例性地列举了第一车机信号的可能形式，可以理解，在实际实现时，本技术实施例不限于此，即上述第一车机信号还可以是其他可能的与车辆应用相关的信号或资源，具体可以根据实际使用需求确定，本技术实施例不作限定。
71.在本技术实施例中，当车机设备接收到第一应用对第一车机信号的访问请求时，车机设备可以采集第一车辆的目标参数，例如目标参数可以包括以下至少一项：车辆故障检测结果，行驶速度，位于驾驶座上的驾驶人员的人脸图像。然后，车机设备可以根据目标参数，确定第一车辆处于预设场景模式。
72.示例性地，若第一车辆的车辆故障检测结果指示车辆发生故障，则确定第一车辆处于紧急模式。其中，车机设备可以获取到第一车辆的传感器检测数据，并且根据传感器检测数据，可以确定车辆是否发生故障(例如爆胎、碰撞等)，以此判断车辆当前所处场景模式。
73.若第一车辆的行驶速度大于或等于预设速度阈值，则确定第一车辆处于驾驶模式。其中，车机设备可以获取到第一车辆的车速传感器检测数据，并且根据车速传感器检测数据，可以确定车辆行驶速度是否大于或等于预设速度阈值，以此判断车辆当前所处场景模式。
74.若第一车辆的行驶速度小于预设速度阈值，例如车辆处于停车且车机系统启动的状态，则确定第一车辆处于非驾驶模式。
75.若位于第一车辆的驾驶座上的驾驶人员的人脸图像与预设人脸图像的匹配度小于匹配度阈值，则确定第一车辆处于访客模式。其中，预设人脸图像为预先录入的车主人脸图像。具体地，可以通过车辆中的摄像头采集驾驶人员的人脸图像，并进行人脸识别，以判断驾驶人员是否为车主本人。若检测到驾驶人员并非车主本人，则确定第一车辆处于访客模式。
76.s120，当第一车辆处于预设场景模式时，车机设备判断第一车机信号在预设场景模式下是否支持被访问。
77.一方面，若第一车机信号在预设场景模式下不支持被访问，则车机设备继续执行下述的s130。另一方面，若第一车机信号在预设场景模式下支持被访问，则车机设备继续执行下述的s130。如此可以针对特定场景，采用针对性的信号访问控制策略，实现了不同场景采用不同管控策略，提升车辆安全性。
78.可选的，车辆支持的场景模式可以划分为：驾驶模式、紧急模式和访客模式，还可以包括其他可能的模式(例如非驾驶模式)。为了便于说明，下文中以驾驶模式、紧急模式、访客模式和非驾驶模式为例进行示例性说明。
79.具体到本技术实施例，上述预设场景模式可以为紧急模式，也可以为驾驶模式，还可以为非驾驶模式，或者可以为访客模式，或者为上述各种模式的可能组合，当然还可以为其他任意可能的模式，具体可以根据实际使用需求确定，本技术实施例不作限定。
80.针对车辆的特殊性，本技术实施例提供支持自定义场景模式的管控策略。由于车辆设备的特殊性，对于同一信号，在不同模式下将会有不同的管控级别，比如车门在车辆停止(非驾驶模式)时，认为车门支持app控制，但当车辆在行驶(驾驶模式)中，认为车门是需要严格管控的，随意被app控制，将会带来不可预期的严重危险，影响驾驶安全，因此此时不
允许app控制。
81.在本技术实施例中，可以有针对性地设置不同模式对应的访问权限默认信息，下面通过表1示例性地给出了不同模式对应的访问权限默认信息以及效果。
82.表1
[0083][0084]
其中，根据不同模式对应的访问权限默认信息，车机设备可以判断请求访问的信号在预设场景模式下是否支持被访问，以及是否需要权限校验。
[0085]
对于驾驶模式，在出厂设置阶段，一些影响驾驶安全的信号(比如用于调节驾驶员座椅的车机信号)的设置权限默认为关闭状态，即不允许app设置，以保障驾驶安全。换言之，在驾驶模式下，将威胁到驾驶安全的信号在驾驶模式下关闭设置权限，此时即使app拥有该信号的设置权限也无法设置该信号。
[0086]
对于紧急模式，在出厂设置阶段，一些有助于紧急救援的车机信号(比如用于请求紧急救援的控制信号)权限默认为开放状态，即无需进行权限校验，直接可访问。换言之，在紧急模式下，将允许app直接访问紧急模式下的信号，不需要权限校验，用于紧急救援等功能。
[0087]
对于访客模式，在出厂设置阶段，可以默认开放部分信号(用户可自定义是否开放)，以及默认其他所有信号禁止访问(例如设置和读取)，以保护车主隐私以及车辆安全。并且，若app要访问这些开放的信号，则需要具有信号访问权限才能正常访问。换言之，在访客模式下，仅开放部分自定义的不涉及隐私和安全的信号，其他信号默认禁止访问。
[0088]
对于非驾驶模式(例如停车状态)，在出厂设置阶段，可以不对各种车机信号的访问权限做特殊处理。
[0089]
s130，第一车辆禁止第一应用访问第一车机信号。
[0090]
即，当第一车辆处于预设场景模式时，若第一车机信号在预设场景模式下不支持被访问，则车机设备禁止第一应用访问第一车机信号。
[0091]
示例性的，在车辆行驶过程中，由于用户(例如驾驶人员)误操作而接触到车门开启按钮，触发对控制车门开启的信号(即上述第一车机信号)访问的请求。相应地，车机设备会接收到该请求，检测到车辆当前处于驾驶模式(即上述预设场景模式)，由于控制车门开启的信号在驾驶场景模式下不支持被访问，因此车机设备不调用控制车门开启的信号。这样，用户在驾车过程中的误操作不会触发车门开启，即此时用户的误操作无效，从而可以保障驾车安全性。在实际实现时，将威胁到驾驶安全的信号在驾驶模式下关闭访问权限，此时
应用无法访问该信号。
[0092]
可选地，在车机设备禁止第一应用访问第一车机信号的情况下，为了更好地满足用户的使用需求，车机设备可以输出提示信息，提示用户是否需要对第一车机信号的访问请求进行授权。
[0093]
示例性的，假设控制天窗开启的信号在驾驶场景模式下不支持被访问，那么在请求访问控制天窗开启的信号时，车机设备不调用控制天窗开启的信号，在此情况下，车机设备可以提示用户是否授权在驾驶时车门可开启，并根据用户的输入操作(例如同意授权或不同意授权)，则控制车门开启或者不开启。
[0094]
可选地，上述用户授权可以为一次性授权，即对于本次请求有效的授权；也可以为长期授权，即对于预设时间范围内的访问请求均有效的授权。
[0095]
s140，当第一车机信号支持被访问时，第一车辆判断是否需要权限校验。
[0096]
当第一车辆处于预设场景模式时，若第一车机信号在预设场景模式下支持被访问，则车机设备根据是否需要权限校验，允许或者禁止第一应用访问第一车机信号。例如，对于第一车机信号在预设场景模式下支持被访问的情况，在某些涉及紧急救援的场景下无需进行权限校验，可直接访问，以快速避险，保障驾车安全性；而在一些涉及车辆驾驶安全和/或用户(车主)隐私信息的场景下需要进行权限校验，以保障驾车安全性和用户隐私。
[0097]
一方面，若无需权限校验，则车机设备继续执行下述的s150。另一方面，若需要权限校验，则车机设备继续执行下述的s160。
[0098]
s150，第一车辆允许第一应用访问第一车机信号。
[0099]
即，若第一车机信号在预设场景模式下支持被访问且无需权限校验，则车机设备允许第一应用访问第一车机信号。
[0100]
示例性地，在车辆处于紧急模式时，若待访问的信号属于紧急模式下开放的信号，则可以跳过权限管控，直接访问(设置和读取)信号。即使应用没有申请该信号的访问权限，也能访问。
[0101]
s160，车机设备判断第一应用是否具有访问第一车机信号的权限。
[0102]
其中，若第一车机信号在预设场景模式下支持被访问且需要权限校验，则车机设备对第一应用进行权限校验，并且根据权限校验结果，允许或者禁止第一应用访问第一车机信号。
[0103]
一方面，若第一应用具有访问第一车机信号的权限，则车机设备继续执行上述的s150，即车机设备允许第一应用访问第一车机信号。另一方面，若第一应用不具有访问第一车机信号的权限，则车机设备继续执行上述的s130，即车机设备禁止第一应用访问第一车机信号。
[0104]
本技术实施例采用场景化管控和权限管控融合的管控方法，当app调用车机设备接口以访问车机信号时，首先判断系统目前处于什么场景模式下，然后判断是否进行权限校验，下面进行示例性说明。
[0105]
场景1，在实际应用中，如果在驾驶模式下app请求设置有关影响驾驶安全的车机信号(例如用于控制车门开启的信号)，则拒绝设置。如果在驾驶模式下app请求设置其他信号，则需要校验权限，若有权限则正常设置，若没有权限则禁止设置。
[0106]
需要说明的是，若在驾驶模式下app请求读取信号(用于获取空调温度的信号)，则
执行权限校验，当app拥有该信号的读取权限，则能正常读取，否则不能读取。
[0107]
场景2，在实际应用中，如果在紧急模式下app请求访问这一类有助于紧急救援的车机信号，即该车机信号属于紧急模式下开放的信号，那么跳过权限管控，直接访问信号(例如设置和读取)。在一些实施例中，即使app没有申请该信号的访问权限，也能访问该信号。
[0108]
如果在紧急模式下app请求访问其他信号，那么需要进行权限校验，若权限校验成功则能访问信号，若权限校验失败则无权访问。
[0109]
场景3，在实际应用中，如果在访客模式下app请求访问被禁止访问的车机信号，则拒绝访问。如果在访客模式下app请求访问其他信号，则需要校验权限，若有权限则正常设置，若没有权限则禁止设置。
[0110]
场景4，在实际应用中，如果在非驾驶模式下app请求访问某一车机信号，则进行权限校验。若app有该信号的访问权限，则能正常访问(设置和读取)，否则不能访问。
[0111]
通过上述方案，当app调用车机设备接口以访问车机信号时，首先判断系统目前处于什么场景模式下，然后判断请求访问的车机信号在当前场景模式下是否支持被访问，在不支持访问的情况下禁止访问车机信号，而在支持被访问的情况下判断是否需要权限校验；在无需权限校验时直接访问车机信号，在需要权限校验时根据校验结果允许或禁止访问车机信号。本技术方案在不同场景下采用的信号权限访问机制不同，实现基于场景模式的车辆权限管控，可提升车辆驾驶安全性及信息安全性。
[0112]
可选的，在本技术实施例中，车机设备可以通过多种可能的实现方式对第一应用进行权限校验，下面通过第一实现方式和第二实现方式进行示例性说明。
[0113]
第一实现方式
[0114]
在第一实现方式中，在第一车机信号在预设场景模式下支持被访问且需要权限校验的情况下，车机设备可以输出提示信息，询问用户是否授权，并根据用户输入(同意授权或不同意授权)进行权限校验。具体步骤如下：车机设备可以输出第一提示信息，用于提示是否同意第一应用对第一车机信号的访问权限。车机设备可以根据用户对第一提示信息的响应输入，得到权限校验结果。
[0115]
其中，车机设备可以采用文字提示的方式输出第一提示信息(例如在车机设备的显示屏上显示第一提示信息)，也可以采用语音提示的方式输出第一提示信息，或者可以采用其他任意可行的方式输出第一提示信息，具体可以根据实际使用需求确定，本技术实施例不作限定。
[0116]
可选的，上述第一提示信息可以包括至少一个选项，供用户选择。该至少一个选项可以包括如下两个选项：同意授权，以及拒绝授权(或者不同意授权)，这两项针对的是第一车机信号的访问权限。当然，该至少一个选项还可以包括如下选项：同意授权对同类信号访问(简称为授权同类信号权限)，和/或，查看该同类信号对应的访问权限信息(简称为查看该类信号权限)，该同类信号为与第一车机信号属于相同访问控制等级的信号。
[0117]
示例性地，如图2所示，在显示屏21上显示有第一提示信息，该第一提示信息包含提示内容“是否同意第一应用访问第一车机信号”22，以及“同意”选项23、“不同意”选项24，“授权同类信号权限”选项25和“查看该类信号权限”选项26，供用户选择。若用户选择“同意”选项23，则得到的权限校验结果指示第一应用具有访问第一车机信号的权限。若用户选
择“不同意”选项24，则得到的权限校验结果指示第一应用不具有访问第一车机信号的权限。若用户选择“授权同类信号权限”选项25，则对于与第一车机信号具有相同访问控制等级的所有信号，第一应用均具有访问权限。若用户选择“查看该类信号权限”选项26，则可以显示与第一车机信号具有相同访问控制等级的所有信号的访问权限信息。
[0118]
第二实现方式
[0119]
在第二实现方式中，在第一车机信号在预设场景模式下支持被访问且需要权限校验的情况下，车机设备可以直接调用预先存储的与第一应用对应的访问权限信息，对第一应用进行权限校验，以判断第一应用是否具有访问第一车机信号的权限。
[0120]
具体地，一方面，若第一应用对应的访问权限信息指示：第一应用允许访问第一车机信号，则车机设备根据预先存储的访问权限信息确定第一应用具有访问第一车机信号的权限。另一方面，若第一应用对应的访问权限信息指示：第一应用禁止访问第一车机信号，则车机设备根据预先存储的访问权限信息确定第一应用不具有访问第一车机信号的权限。
[0121]
可选地，在本技术实施例中，上述预先存储的访问权限信息可以由系统设定，也可以由用户自定义设定，具体可以根据实际使用需求确定，本技术实施例不作限定。例如，若第一应用为系统应用，则与第一应用对应的访问权限信息可以由系统设定，并且允许用户后期自定义设定。若第一应用为第三方应用，则与第一应用对应的访问权限信息可以由用户自定义设定。
[0122]
下面详细描述预先存储的访问权限信息由用户自定义设定的几种可能情况。可选地，车机设备可以支持用户被动设定访问权限信息，也支持用户主动设定访问权限信息。以下通过方式一和方式二对如何预先存储访问权限信息进行示例性说明。
[0123]
方式一，当车机设备检测到车机设备初次安装第一应用并运行第一应用时，车机设备输出第二提示信息，用于提示是否同意第一应用的访问权限；并且车机设备可以根据用户对第二提示信息的响应输入，存储与第一应用对应的访问权限信息。
[0124]
其中，车机设备可以采用文字提示的方式输出第二提示信息，也可以采用语音提示的方式输出第二提示信息，或者可以采用其他任意可行的方式输出第二提示信息，具体可以根据实际使用需求确定，本技术实施例不作限定。
[0125]
示例性地，以文字提示的方式为例，当车机设备初次安装app1并运行app1时，车机设备可以在显示屏上显示消息提示框，该消息提示框中可以显示第二提示信息的内容，例如“是否同意app1访问车载摄像头数据的权限”，以及“同意”选项和“不同意”选项，供用户选择。若用户选择“同意”选项，则车机设备根据用户输入，存储与app1对应的访问权限信息：app1具有访问车载摄像头数据的权限。
[0126]
如此，与第一应用对应的访问权限信息由用户设定并预先存储在车机设备中，以便于在第一应用有访问请求时，车机设备可以根据该访问权限信息对第一应用进行权限校验。具体到本方案，当第一应用有请求访问第一车机信号时，车机设备可以根据预先存储的访问权限信息，确定第一应用是否具有访问第一车机信号的权限。
[0127]
方式二，在车机设备安装有第一应用的情况下，根据用户在权限管理界面中对第一应用的访问权限进行的设置操作，存储与第一应用对应的访问权限信息。
[0128]
示例性地，当车机设备已安装有app1的情况下，用户可以根据个人使用需求，在车机设备的显示屏显示的权限管理界面中对app1的访问权限进行设置操作。例如，若用户将“app1具有访问车载摄像头数据的权限”修改为“app1不具有访问车载摄像头数据的权限”，则车机设备可以响应于用户操作，更新存储与app1对应的访问权限信息：app1不具有访问车载摄像头数据的权限。
[0129]
如此，与第一应用对应的访问权限信息经过用户授权后存储在车机设备中，以便于在第一应用访问请求时，车机设备可以根据该访问权限信息对第一应用进行权限校验。
[0130]
在本技术实施例中，车机设备可以预先存储访问控制等级在各种场景模式下的访问权限信息，以下称之为基于场景的权限信息。具体到本方案，车机设备在接收到第一应用对第一车机信号的访问请求时，可以先确定第一车机信号对应的访问控制等级；然后可以根据第一车机信号对应的访问控制等级和预先存储的基于场景的权限信息，确定第一车机信号在预设场景模式下的访问权限。
[0131]
需要说明的是，信号的访问权限可以是指信号的读取权限和/或写入权限。
[0132]
在实际实现时，应用对控制信号的访问，可能是应用对控制信号的读取，或者是指应用对控制信号的写入(即修改设置信息)。具体地，车机设备需要判断应用对控制信号的访问是读取还是写入，并结合预先存储的访问权限信息(例如读取权限和/或写入权限)，确定本次访问是否具有访问权限。
[0133]
示例性地，车机设备可以判断第一应用请求以写入方式访问第一车机信号，还是请求以读取方式访问第一车机信号。进一步地，车机设备可以结合预先存储的访问权限信息，确定本次访问是否具有写入权限或者读取权限；然后，根据本次访问是否具有写入权限或者读取权限，允许(或者禁止)第一应用按照所确定的访问方式访问第一车机信号。
[0134]
例如，若app请求以写入方式访问第一车机信号并且app有写入权限，则允许app以写入方式访问第一车机信号。再例如，若app请求以读取方式访问第一车机信号并且app有读取权限，则允许app以读取方式访问第一车机信号。
[0135]
例如，若app请求以写入方式访问第一车机信号但是app不具有写入权限，则禁止app以写入方式访问第一车机信号。再例如，若app请求以读取方式访问第一车机信号但是app不具有读取权限，则禁止app以读取方式访问第一车机信号。
[0136]
下面示例性地列举了在预设场景模式下信号写入权限和读取权限的不同情况以及每种情况下通过本方案控制访问权限的实现方式。
[0137]
(1)第一车机信号的访问权限默认为在预设场景模式下支持写入，也支持读取。
[0138]
在一些实施例中，在满足(1)访问权限的情况下，若第一应用请求写入第一车机信号，且权限校验成功或者无需权限校验，则车机设备允许第一应用写入第一车机信号；若第一应用请求写入第一车机信号，但权限校验失败，则车机设备禁止第一应用写入第一车机信号。
[0139]
在另一些实施例中，在满足(1)访问权限的情况下，若第一应用请求读取第一车机信号，且权限校验成功或者无需权限校验，则车机设备允许第一应用读取第一车机信号；若第一应用请求写入第一车机信号，但权限校验失败，则车机设备禁止第一应用写入第一车机信号。
[0140]
(2)第一车机信号的访问权限默认为在预设场景模式下支持读取，但不支持写入。
[0141]
在一些实施例中，在满足(2)访问权限的情况下，若第一应用请求读取第一车机信号，且权限校验成功或者无需权限校验，则车机设备允许第一应用读取第一车机信号；若第
一应用请求读取第一车机信号，但权限校验失败，则车机设备禁止第一应用读取第一车机信号。
[0142]
在另一些实施例中，在满足(2)访问权限的情况下，若第一应用请求写入第一车机信号，则车机设备禁止第一应用写入第一车机信号。示例性的，在实际实现时，可以将威胁到驾驶安全的信号在驾驶模式下关闭写入权限(即设置权限)，此时即使应用在其他场景模式下拥有该信号的设置权限，也无法设置该信号。
[0143]
(3)第一车机信号的访问权限默认为在预设场景模式下支持写入，但不支持读取。
[0144]
在一些实施例中，在满足(3)访问权限的情况下，若第一应用请求写入第一车机信号，无需权限校验或者权限校验成功，则车机设备允许第一应用写入第一车机信号；若第一应用请求写入第一车机信号，但权限校验失败，则车机设备禁止第一应用写入第一车机信号。
[0145]
在一些实施例中，在满足(3)访问权限的情况下，若第一应用请求读取第一车机信号，则车机设备禁止第一应用读取第一车机信号。示例性的，在实际实现时，可以将涉及车主个人隐私的信号在访客模式下关闭写入权限和/或读取权限，此时即使应用在其他场景模式下拥有该信号的写入权限和/或读取权限，也无法写入和/或读取该信号。
[0146]
(4)第一车机信号的访问权限默认为在预设场景模式下不支持读取，也不支持写入。
[0147]
在一些实施例中，在满足(4)访问权限的情况下，若第一应用请求读取第一车机信号，则车机设备禁止第一应用读取第一车机信号；若第一应用请求写入第一车机信号，则车机设备禁止第一应用写入第一车机信号。
[0148]
其中，车机设备允许第一应用访问第一车机信号包括如下可能的实现方式：
[0149]
方式一，车机设备将第一车机信号发送给第一应用。可以理解，这对应于上述以读取方式访问第一车机信号的情况。
[0150]
方式二，车机设备接收第一应用发送的第一车机信号，并根据第一车机信号更新对应的车机功能设置信息。可以理解，这对应于上述以写入方式访问第一车机信号的情况。
[0151]
上文以车辆处于单个场景模式的情况为例，介绍了针对不同场景模式的访问权限管控策略，可以理解，在实际实现时，车辆可能处于多个场景模式，这种多场景模式的情况可以通过设定各个场景模式的优先级并按照优先级高低进行处理。下面介绍本方案在多场景模式下的具体实现方式。
[0152]
在一些实施例中，若车机设备检测到目标参数符合至少两种场景模式，则车机设备可以将该至少两种场景模式中优先级较高的场景模式确定为第一车辆的主场景模式，以及将该至少两种场景模式中优先级较低的场景模式确定为第一车辆的次场景模式。示例性地，上述至少两种场景模式可以包括优先级从高到低排列的紧急模式、驾驶模式、访客模式中的至少两项，或者包括优先级从高到低排列的紧急模式、访客模式、非驾驶模式中的至少两项。
[0153]
需要说明的是，当某一信号在主场景模式和次场景模式下的访问权限信息发生冲突时，车机设备可以采用主场景模式对应的信号访问权限信息。
[0154]
示例性地，假设紧急模式的优先级默认高于访客模式的优先级，并且在紧急模式下支持天窗根据用户语音进行调节，而在访客模式不支持天窗根据用户语音进行调节。当
车辆出现故障或者遇险、且检测到车辆处于紧急模式和访客模式时，由于紧急模式作为主场景模式，因此采用紧急模式对应的信号访问权限信息，即支持天窗根据用户语音进行调节；那么，当用户通过语音触发车机设备调节天窗时，车机设备可以响应于用户输入，按照用户语音输入内容调节车窗开启或者关闭，以紧急避险，提升车辆驾驶安全性。
[0155]
通过本方案，能够实现车辆在进入不同模式时，对同一信号进行不同管控，即实现基于场景模式的权限管控，使得车机系统及设备更加智能化和更加安全。
[0156]
以上示例性地说明了本技术实施例提供的车辆访问权限控制方法的实现方式，该车辆访问权限控制方法主要基于本技术实施例提供的车机信号分级别管控规则。下面详细说明本技术实施例定义车机信号访问控制等级所遵循的原则，以及每个访问控制等级在典型场景下对应的权限管控策略。
[0157]
在实际实现时，在应用请求访问车机信号以实现数据读取、设置控制器、信号订阅/去订阅等的场景下，需要进行访问管控。尤其对于辅助驾驶信号等以及驾驶安全相关的信号，需要严格管控。如何合理管控海量app对车辆的访问，哪些app能够访问哪些车辆信号，目前业界并没有一套车辆访问等级规则，因此本技术提出车辆信号级别的管控规则，明确相应级别的信号有相应的管控策略，app可以根据规则和需要申请相应信息的访问权限。
[0158]
针对车机需要建立良好生态的需求，基于车机域信号定义安全规则，对所有车机信号进行管控分级，从而作为开放参考。本技术主要从车机信号的访问安全、风险以及法律法规等方面来进行综合考虑，提出车机信号分级别管控规则。
[0159]
从访问安全和风险角度来看，业界定义了三个安全项：发生问题后的影响大小(严重程度)、发生问题的可能性、特定条件下是否可控制，并针对每个安全项划分了等级。
[0160]
下面的表1示意性地给出了基于严重程度这一安全项划分的等级(例如s0、s1、s2、s3)，表2示意性地给出了基于发生问题的可能性这一安全项划分的等级(例如e0、e1、e2、e3、e4)，表3示意性地给出了基于特定条件下是否可控制这一安全项所划分的等级(例如c0、c1、c2、c3)。具体每个等级对应的内容分别参见下述的表2、表3和表4。
[0161]
表2
[0162][0163]
表3
[0164][0165]
表4
[0166][0167]
参考上述针对每个安全项划分等级的原则，并结合《通用数据保护条例》(general data protection regulation，gdpr)等法律法规，本技术实施例提供的鸿蒙安全子系统定
义出车机信号访问控制等级(access control level，acl)，例如下述表5中的acl0至acl4，以提供完善的安全管控能力。其中，针对恶意车机信号访问产生的负面影响程度，遵从“从严不从松”的等级定义原则。
[0168]
如图5所示，本技术实施例提出对不同的控制信号进行分级管控，不同控制信号归类为不同访问控制等级，在每个访问控制等级中，各个场景模式下对信号访问权限的规则设定不同。
[0169]
需要说明的是，表5所示的访问控制等级的划分为示例性地说明，在实际实现时，可以根据实际使用需求对访问控制等级进行划分，本技术实施例不作限定。本技术实施例提供的车辆信号等级划分规则，有利于推动业界车辆安全的统一性，有利于推动车辆生态的发展。
[0170]
表5
[0171][0172]
在本技术实施中，依据上述表5所述的访问控制等级划分原则，可以建立访问控制等级在各种场景模式下的访问权限，并预先存储基于场景的权限信息，用于指示访问控制等级在各种场景模式下的访问权限。
[0173]
具体到本技术方案，车机设备在接收到第一应用对第一车机信号的访问请求时，可以先确定第一车机信号对应的访问控制等级；然后，根据第一车机信号对应的访问控制等级和预先存储的基于场景的权限信息，确定第一车机信号在预设场景模式下的访问权限。
[0174]
示例性地，在驾驶模式下若app调用车机设备接口以访问用于控制车门打开的车机信号，则由于请求访问的车机信号所触发的结果有致命安全隐患，确定该车机信号对应的访问控制等级为acl4，然后由于预先存储的acl4对应的基于场景的权限信息包括如下信息：触发车门开启的车机信号被禁止访问，因此确定该车机信号在驾驶模式下没有访问权限，因此app不会触发车门开启，这样可以避免驾驶危险隐患。
[0175]
下面结合图3示例性地描述如何通过应用与车机设备之间的交互来实现访问权限管控的流程。参见图3，示出了本技术实施例提供的访问权限管控的流程示意图。
[0176]
s301，在车机专有硬件服务拉起或启动时进行初始化。
[0177]
一方面，车机专有硬件服务系统(以下简称为车机服务系统)读取自定义分级配置文件，完成对权限管控配置文件的加载及解析，获取车机专有硬件权限群组。
[0178]
另一方面，安全子系统读取安全权限管控配置文件，完成对权限管控配置文件的加载及解析，获取系统权限群组，并加载车机信号名和权限名称的映射关系。
[0179]
如图3所示，针对第三方app动态权限管控的时序图如下：
[0180]
s302，当用户触发第三方app首次安装、版本更新或者执行某一功能(例如获取空调温度)时，第三方app向安全子系统申请权限。
[0181]
s303，安全子系统(例如权限控制模块)弹窗提示：是否授予第三方app权限(例如是否授予获取空调温度的权限)。
[0182]
s304，安全子系统接收用户授予第三方app权限的操作，存储第三方app的权限信息(例如第三方app具有获取空调温度的权限)。
[0183]
s305，安全子系统通知第三方app获得权限(例如第三方app具有获取空调温度的权限)。
[0184]
s306，第三方app向车机服务系统发送车机信号访问请求，以调用车机服务系统的接口访问信息(例如获取空调温度)。
[0185]
s307，车机服务系统调用安全子系统进行权限校验。
[0186]
s308，安全子系统根据已存储的第三方app的权限信息进行权限校验，并通知车机服务系统第三方app有权限。
[0187]
其中，安全子系统基于车机信号名和权限名称的映射关系，根据车机信号名获取对应的权限名称，校验该车机信号访问请求的合法性，若已授权，则继续执行s309，否则向车机服务系统反馈无权限。
[0188]
s309，车机服务系统在确定第三方app有权限的情况下，响应于第三方app的车机信号访问请求进行业务处理，并向第三方app返回信息(例如返回空调温度信息)。
[0189]
再参考图3，针对系统app(或oem)动态权限管控的时序图如下：
[0190]
s310，响应于用户对系统app的触发操作，系统app向车机服务系统发送车机信号访问请求，以调用车机服务系统的接口访问信息(例如获取空调温度)。
[0191]
s311，车机服务系统调用安全子系统进行权限校验。
[0192]
s312，安全子系统进行权限校验，并通知车机服务系统第三方app有权限。
[0193]
其中，安全子系统基于车机信号名和权限名称的映射关系，根据车机信号名获取对应的权限名称，校验该车机信号访问请求的合法性，若已授权，则继续执行s313，否则向车机服务系统反馈无权限。
[0194]
s313，车机服务系统在确定系统app有权限的情况下，响应于系统app的车机信号访问请求进行业务处理，并向系统app返回信息(例如返回空调温度信息)。
[0195]
本技术利用鸿蒙安全子系统提供的权限校验能力，结合本技术提出的车机信号分级策略，实现鸿蒙车机操作系统的权限管控。
[0196]
下面结合图4示例性地描述如何通过应用与车机设备之间的交互来实现不同场景
模式下的访问权限管控的流程。参见图4，示出了本技术实施例提供的鸿蒙车机安全管控策略的流程示意图。
[0197]
s410，应用调用车机服务系统的api接口，请求访问车机专有硬件信号。
[0198]
s420，通过api接口进行进程间通信(inter-process communication，ipc)，向车机服务系统发起请求，获取到车机专有硬件服务。
[0199]
s430，车机服务系统的场景管控模块判断当前系统处于什么场景模式。
[0200]
s440，根据请求访问的信号在当前系统所处的场景模式下的访问权限，执行对应操作：
[0201]
a)如果当前系统处于紧急模式，那么判断请求访问的信号是否属于紧急模式下的信号：若属于紧急模式下的信号，则将直接访问(s441)；如果当前系统处于紧急模式但请求访问的信号不属于紧急模式(s442)，则执行下述的s450。
[0202]
b)如果是驾驶模式或非驾驶模式或其他模式，那么判断请求访问的信号是否支持访问(或者是否被禁止访问)：若支持访问(没有被禁止访问，即s443)，则执行下述的s450；若不支持访问(被禁止访问)，则直接拒绝访问(s444)；其中，可以通过硬件接口向应用反馈信号被禁止访问。
[0203]
s450，车机服务系统的权限管控模块执行权限校验。
[0204]
其中，车机服务系统的权限管控模块首先将请求访问的信号映射成权限名，然后调用鸿蒙安全子系统的权限校验功能，进行访问管控：若有访问权限则支持访问车机信号数据，若无访问权限则拒绝访问。
[0205]
s461，若无信号访问权限，则不支持访问。其中，可以通过硬件接口向应用反馈由于无访问权限导致信号不支持访问。
[0206]
s462，若有信号访问权限，则支持访问，执行下述的s470。
[0207]
s470，车机服务系统的硬件响应于访问请求，向硬件接口返回访问结果。
[0208]
s480，通过硬件接口，向应用返回访问结果。
[0209]
通过上述方案，本技术实施例可以根据场景模式不同，实现车辆控制信号的差异性安全管控，提升车辆驾驶安全性。
[0210]
本技术实施例还提供一种车机设备，也称为车载终端，该车机设备可以应用本技术实施例提供的上述车辆访问权限控制方法。
[0211]
其中，该车机设备上可以加载有大量的第三方app或系统app。当用户通过在第三方app或系统app上操作以触发车辆执行某一功能时，通过上述车辆访问权限控制方法，先检测车辆当前状态(即所处场景模式)，并判断与该功能对应的第一车机信号在该场景模式下的访问权限，根据访问权限确定是否执行该功能：在系统允许访问与该第一车机信号的情况下才能实现这一功能，在系统不允许访问与该第一车机信号的情况下这一功能无法实现。这里，“允许访问”的条件可以指支持访问且权限校验成功，或者指支持访问且无需权限校验；“不允许访问”的条件可以指不支持访问，或者指支持访问但权限校验失败。
[0212]
本技术实施例中的车机设备可以为具有操作系统(operation system，os)的车机设备。该操作系统可以为鸿蒙操作系统，还可以为其他可能的操作系统，本技术实施例不作具体限定，下面以鸿蒙车机os为例进行示例性说明。开发人员可以基于该操作系统的系统架构，开发实现本技术实施例提供的车辆访问权限控制方法的软件程序，从而使得该车辆
访问权限控制方法可以基于该操作系统运行。即车机设备或者处理器可以通过在操作系统中运行该软件程序实现本技术实施例提供的车辆访问权限控制方法。
[0213]
车机系统不但面向消费者以提供保障安全，也会面向原始设备制造商(original equipment manufacturer，oem)开发者，使得开发者更加方便快捷地开发，如何做到在保证车辆驾驶安全的前提下，构建用户体验好且便于开发者开发的安全管控方法显得尤为重要。因此本技术提供便于开发者开发的策略，实现权限管控的灵活配置。其中，考虑到操作系统版本与oem产品版本的差异性，本技术实施例提出支持oem厂商(或者车厂)自定义权限管控的策略方案，可实现os版本与oem产品版本的解耦。这样，车机os与车厂之间实现解耦，非常便于车厂自定义或者重定义车机信号权限。
[0214]
具体地，如图5所示，oem厂商可以基于系统厂商提供的车机os，结合本技术上述实施例提供的车机信号等级划分策略，针对不同的车型实现不同的权限配置。
[0215]
一方面，安全子系统可以读取权限管控配置文件和信号配置文件，初始化车机os的默认权限定义；另一方面，oem厂商可以基于该安全子系统，自定义系统权限，例如新增权限定义，或者修改已有的权限定义。
[0216]
在一些实施例中，oem厂商可以新增车机信号。示例性地，在鸿蒙车机os的hap格式的应用安装包中可以新增车机信号对应的权限定义，还可以在权限管控配置文件中新增车机信号名及其权限名。
[0217]
需要说明的是，oem厂商可以基于鸿蒙车机os开发app的集成开发环境(integrated development environment，ide)，编译生成鸿蒙hap应用的软件安装包，可以在系统生效情况下新增信号权限。
[0218]
在一些实施例中，oem厂商可以修改已有信号的权限信息。示例性地，在鸿蒙车机os的hap格式的安装包中可以新增或修改该信号对应的权限定义，还可以修改权限管控配置文件中该信号名对应的权限名。
[0219]
需要说明的是，鸿蒙车机os采用场景化配置文件和权限管控配置文件来实现oem厂商与os版本的解耦。其中，这两项配置文件可采用xml格式，场景化配置文件可以包括车机信号名、场景模式以及是否支持访问等信息；权限管控配置文件可以包括车机信号名、权限等级以及读写权限名等信息。首先，oem厂商按照配置文件格式，自定义信号管控策略；然后，在鸿蒙车机os启动时加载并解析配置文件，完成安全管控的初始化，使得信号管控生效。
[0220]
在本技术实施例中，首先，车机专有硬件服务提供权限管控配置文件，在服务系统拉起时，读取该权限管控配置文件，完成车机信号和权限名称的映射关系。其次，oem厂商可以通过鸿蒙hap应用，定义权限名称和权限等级，然后通过修改车机专有硬件服务提供的权限管控配置文件，完成信号权限名称的重定义和自定义。
[0221]
示例性地，车机专有硬件服务提供的权限管控配置文件的格式如下：
[0222][0223]
其中，《permission》《/permission》为权限配置的标识；《signal》《/signal》为一个车机信号节点；《name》《/name》为车机信号名；《description》《/description》为上面提供的车机信号权限等级(例如acl0～acl4)；《getpermission》《/getpermission》为车机信号的读权限，若为空则代表此车机信号不支持读取；《setpermission》《/setpermission》为车机信号的设置权限，若为空则代表此车机信号不支持设置。
[0224]
在本技术实施例中为了支持oem厂商扩展和使用，本技术实施例还支持oem厂商自定义场景模式，以及支持配置该场景模式下信号是否支持访问。通过提供场景模式配置文件，在车机os启动时会读取该配置文件，从而达到基于场景模式的信号管控，实现鸿蒙车机更加智能化、更加安全地管控。
[0225]
示例性地，车机专有硬件服务提供的场景模式管控配置文件的格式如下：
[0226][0227][0228]
其中，《scene》《/scene》为整个场景模式管控配置的标识；《signal》《/signal》为一个场景模式配置的节点；《name》《/name》为一个车机信号名称的配置项；《mode》《/mode》为该车机信号在哪种场景模式下生效；《enable》《/enable》支持配置true或false，true代表该车机信号在该模式下支持访问，false代表该车机信号在该模式下不支持访问。
[0229]
需要说明的是，当车机服务系统启动时，场景管控模块会加载并解析场景化配置文件，完成初始化。当系统进入到不同模式，将会对访问的信号进行管控，从而达到一种支持场景化信号管控的方法，保障车辆安全。
[0230]
综上所述，本技术实施例提供支持oem厂商自定义权限的管控策略方案，实现车机os与oem厂商的解耦，方便开发者开发。
[0231]
现有技术中，车机系统对车机信号的管控，缺失车机信号分类管控的策略规则，而且不能根据不同场景实现不同管控，显得不够灵活；有些车机系统比较封闭，大部分信号不开放权限，仅对部分信号开放权限，可以理解为无权限管控机制，无法构建车辆生态，不利于开发者修改权限。与现有技术相比，本技术实施例提出了车机信号级别管控规则，有利于建立鸿蒙车机生态；另外提出的支持oem厂商自定义权限管控策略方案，有利于三方oem厂
商的权限开发；并且利用安全子系统的权限检验功能，建立安全可靠的车机os。
[0232]
本技术实施例还提供一种车辆，该车辆包括上述实施例中的车机设备。其中，该车机设备可以按照上述方法实施例中的基于场景模式的权限管控策略，控制对该车辆的访问权限。
[0233]
其中，车辆还包括显示器、各种传感器以及摄像装置等器件，车机设备通过与这些器件进行交互，实现对该车辆的访问权限的管控。在本技术实施例中，基于上述方法实施例中提到的在不同模式下，信号的管控方式可以不同，通过本技术方案，可以实现车辆在不同场景下，实现不同的管控。
[0234]
本文中描述的各个实施例可以为独立的方案，也可以根据内在逻辑进行组合，这些方案都落入本技术的保护范围中。
[0235]
可以理解的是，上述各个方法实施例中由车机设备实现的方法和操作，也可以由可用于车机设备的部件(例如芯片或者电路)实现。
[0236]
上文描述了本技术提供的方法实施例，下文将描述本技术提供的装置实施例。应理解，装置实施例的描述与方法实施例的描述相互对应，因此，未详细描述的内容可以参见上文方法实施例，为了简洁，这里不再赘述。
[0237]
上文主要从方法步骤的角度对本技术实施例提供的方案进行了描述。可以理解的是，为了实现上述功能，实施该方法的车机设备包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本技术能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的保护范围。
[0238]
本技术实施例可以根据上述方法示例，对车机设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本技术实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有其它可行的划分方式。下面以采用对应各个功能划分各个功能模块为例进行说明。
[0239]
图6为本技术实施例提供的车辆访问权限控制装置800的示意性框图。该装置800可以用于执行上文方法实施例中车机设备所执行的动作。该装置800包括检测单元810和处理单元820。
[0240]
检测单元810，用于在接收到第一应用对第一车机信号的访问请求时，检测第一车辆处于预设场景模式。其中，第一应用为第一车辆的车机设备上加载的应用。
[0241]
处理单元820，用于：
[0242]
若第一车机信号在预设场景模式下不支持被访问，则禁止第一应用访问第一车机信号；
[0243]
或者，若第一车机信号在预设场景模式下支持被访问且无需权限校验，则允许第一应用访问第一车机信号；
[0244]
或者，若第一车机信号在预设场景模式下支持被访问且需要权限校验，则对第一
应用进行权限校验，并且根据权限校验结果，允许或者禁止第一应用访问第一车机信号。
[0245]
其中，第一应用可以为系统app，也可以为第三方app。
[0246]
在一些可能实现方式中，假设第一车机信号在预设场景模式下支持被访问且需要权限校验，那么处理单元820具体用于：若权限校验结果指示第一应用有访问权限，则允许第一应用访问第一车机信号；或者，若权限校验结果指示第一应用无访问权限，则禁止第一应用访问第一车机信号。
[0247]
在一些可能实现方式中，处理单元820还用于：确定第一应用请求访问第一车机信号对应的目标访问方式，该目标访问方式为以写入方式访问或者以读取方式访问。
[0248]
在此情况下，处理单元820具体用于：允许或者禁止第一应用按照目标访问方式访问第一车机信号。
[0249]
在一些可能实现方式中，处理单元820具体用于：输出第一提示信息，用于提示是否同意第一应用对第一车机信号的访问权限；根据用户对第一提示信息的响应输入，得到权限校验结果。
[0250]
其中，上述权限校验结果指示第一应用具有访问第一车机信号的权限，或者权限校验结果指示第一应用不具有访问第一车机信号的权限。
[0251]
在一些可能实现方式中，上述第一提示信息包括至少一个选项，该至少一个选项包括以下至少一项：拒绝授予对第一车机信号访问的权限、同意授予对第一车机信号访问的权限、同意授予对同类信号访问的权限、查看同类信号对应的访问权限信息，该同类信号为与第一车机信号属于相同访问控制等级的信号。
[0252]
在一些可能实现方式中，处理单元820具体用于：根据预先存储的与第一应用对应的访问权限信息，确定第一应用是否具有访问第一车机信号的权限。
[0253]
示例性地，处理单元820具体用于：若第一应用对应的访问权限信息指示第一应用允许访问第一车机信号，则确定第一应用具有访问第一车机信号的权限；或者，若第一应用对应的访问权限信息指示第一应用禁止访问第一车机信号，则确定第一应用不具有访问第一车机信号的权限。
[0254]
在一些可能实现方式中，处理单元820具体用于：当检测单元810检测到车机设备初次安装第一应用并运行第一应用时，输出第二提示信息，用于提示是否同意第一应用的访问权限；根据用户对第二提示信息的响应输入，存储与第一应用对应的访问权限信息。
[0255]
或者，处理单元820具体用于：在车机设备安装有第一应用的情况下，根据用户在权限管理界面中对第一应用的访问权限进行的设置操作，存储与第一应用对应的访问权限信息。
[0256]
在一些可能实现方式中，处理单元820还用于：在接收到第一应用对第一车机信号的访问请求时，确定第一车机信号对应的访问控制等级；并根据第一车机信号对应的访问控制等级和预先存储的基于场景的权限信息，确定第一车机信号在预设场景模式下的访问权限；其中，该基于场景的权限信息用于指示访问控制等级在各种场景模式下的访问权限。
[0257]
在一些可能实现方式中，处理单元820允许第一应用访问第一车机信号，具体包括：处理单元820用于向第一应用发送第一车机信号；或者，接收第一应用发送的第一车机信号，并根据第一车机信号更新与第一车机信号对应的车机功能设置信息。
[0258]
在一些可能实现方式中，检测单元810具体用于：采集第一车辆的目标参数，该目
processing unit，cpu)。该处理器还可以是其它通用处理器、数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现成可编程门阵列(field programmable gate array，fpga)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。或者该处理器910采用一个或多个集成电路，用于执行相关程序，以实现本技术实施例所提供的技术方案。
[0269]
该存储器920可以包括只读存储器和随机存取存储器，并向处理器910提供指令和数据。处理器910的一部分还可以包括非易失性随机存取存储器。例如，处理器910还可以存储设备类型的信息。
[0270]
在车机设备900运行时，处理器910执行存储器920中的计算机执行指令以执行上述方法的操作步骤。
[0271]
应理解，根据本技术实施例的车机设备900可对应于本技术实施例中的装置800，并且装置800中的各个单元的上述和其它操作和/或功能分别为了实现上述方法的相应流程，为了简洁，在此不再赘述。
[0272]
可选地，在一些实施例中，本技术实施例还提供了一种计算机可读介质，该计算机可读介质存储有程序代码，当计算机程序代码在计算机上运行时，使得计算机执行上述各方面中的方法。
[0273]
可选地，在一些实施例中，本技术实施例还提供了一种计算机程序产品，该计算机程序产品包括：计算机程序代码，当计算机程序代码在计算机上运行时，使得计算机执行上述各方面中的方法。
[0274]
在本技术实施例中，车机设备包括硬件层、运行在硬件层之上的操作系统层，以及运行在操作系统层上的应用层。其中，硬件层可以包括中央处理器(central processing unit，cpu)、内存管理单元(memory management unit，mmu)和内存(也称为主存)等硬件。操作系统层的操作系统可以是任意一种或多种通过进程(process)实现业务处理的计算机操作系统，例如，鸿蒙操作系统、linux操作系统、unix操作系统、android操作系统、ios操作系统或windows操作系统等。应用层可以包含驾驶辅助软件、导航软件、音视频软件、通讯录、文字处理软件、即时通信软件等应用。
[0275]
本技术实施例并未对本技术实施例提供的方法的执行主体的具体结构进行特别限定，只要能够通过运行记录有本技术实施例提供的方法的代码的程序，以根据本技术实施例提供的方法进行通信即可。例如，本技术实施例提供的方法的执行主体可以是车机设备，或者，是车机设备中能够调用程序并执行程序的功能模块。
[0276]
本技术的各个方面或特征可以实现成方法、装置或使用标准编程和/或工程技术的制品。本文中使用的术语“制品”可以涵盖可从任何计算机可读器件、载体或介质访问的计算机程序。例如，计算机可读介质可以包括但不限于：磁存储器件(例如，硬盘、软盘或磁带等)，光盘(例如，压缩盘(compact disc，cd)、数字通用盘(digital versatile disc，dvd)等)，智能卡和闪存器件(例如，可擦写可编程只读存储器、卡、棒或钥匙驱动器等)。
[0277]
本文描述的各种存储介质可代表用于存储信息的一个或多个设备和/或其它机器可读介质。术语“机器可读介质”可以包括但不限于：无线信道和能够存储、包含和/或承载指令和/或数据的各种其它介质。
[0278]
应理解，本技术实施例中提及的处理器可以是中央处理单元(central processing unit，cpu)，还可以是其他通用处理器、数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现成可编程门阵列(field programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
[0279]
还应理解，本技术实施例中提及的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，rom)、可编程只读存储器(programmable rom，prom)、可擦除可编程只读存储器(erasable prom，eprom)、电可擦除可编程只读存储器(electrically eprom，eeprom)或闪存。易失性存储器可以是随机存取存储器(random access memory，ram)。例如，ram可以用作外部高速缓存。作为示例而非限定，ram可以包括如下多种形式：静态随机存取存储器(static ram，sram)、动态随机存取存储器(dynamic ram，dram)、同步动态随机存取存储器(synchronous dram，sdram)、双倍数据速率同步动态随机存取存储器(double data rate sdram，ddr sdram)、增强型同步动态随机存取存储器(enhanced sdram，esdram)、同步连接动态随机存取存储器(synchlink dram，sldram)和直接内存总线随机存取存储器(direct rambus ram，dr ram)。
[0280]
需要说明的是，当处理器为通用处理器、dsp、asic、fpga或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件时，存储器(存储模块)可以集成在处理器中。
[0281]
还需要说明的是，本文描述的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
[0282]
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的保护范围。
[0283]
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
[0284]
在本技术所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。此外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
[0285]
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
[0286]
另外，在本技术各个实施例中的各功能单元可以集成在一个单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
[0287]
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上，或者说对现有技术做出贡献的部分，或者该技术方案的部分，可以以计算机软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，该计算机软件产品包括若干指令，该指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本技术各个实施例所述方法的全部或部分步骤。前述的存储介质可以包括但不限于：u盘、移动硬盘、rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。
[0288]
除非另有定义，本文所使用的所有的技术和科学术语与属于本技术的技术领域的技术人员通常理解的含义相同。本文中在本技术的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本技术。
[0289]
以上所述，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以所述权利要求的保护范围为准。