具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员基于本申请所获得的所有其他实施例,都属于本发明保护的范围。
为了减少车辆系统资源的浪费,本发明实施例提供了一种统一的用车情景感知方法及车载系统。
本发明实施例提供的用车情景感知方法可以应用于车载系统,因此,下面首先对本发明实施例提供的车载系统进行介绍。
如图1所示,该车载系统中可以包括数据中心110、情景计算引擎120、多个业务应用130以及情景管理中心140;
所述数据中心110,可以用于获得所述车载系统中各个业务应用130上报的业务数据;
所述情景计算引擎120,可以用于基于用车情景预设的目标情景判断规则中的参数值条件和所述业务数据,获得所需的第一目标业务数据,将所述第一目标业务数据与用车情景预设的目标情景判断规则中的参数值条件进行匹配,获得是否为第一用车情景的判断结果;基于用车情景预设的目标情景识别算法所需的输入参数和所述业务数据,获得目标情景识别算法所需的第二目标业务数据,将所述第二目标业务数据输入至目标情景识别算法对应的情景判断模型中,获得所述情景判断模型输出的是否为第二用车情景的判断结果;所述第一用车情景为业务边界明确的用车情景;所述第二用车情景为非业务边界明确的用车情景;
所述情景管理中心140,可以用于基于所述各个判断结果,确定当前用车情景。
本发明实施例中提供的车载系统,数据中心获取各业务应用上报的业务数据,情景计算引擎基于用车情景预设的目标情景判断规则中的参数值条件和上述业务数据,获得所需的第一目标业务数据,并基于用车情景预设的目标情景识别算法所需的输入参数和上述业务数据,获得目标情景识别算法需要的第二目标业务数据,将第一目标业务数据与预设的目标情景判断规则中的参数值条件进行匹配,得到是否为第一用车情景的判断结果,将第二目标业务数据输入至目标情景识别算法的情景判断模型中,来获得情景判断模型输出的是否为第二用车情景的判断结果,其中,第一用车情景为业务边界明确的用车情景,第二用车情景则是非业务边界明确的用车情景,情景中心基于各判断结果确定当前用车情景。本发明实施例中,可以对各业务应用的业务数据进行统一汇流,从而可以对各业务应用进行统一的情景开发,并可使用各用车情景对应的感知算法基于汇流后的业务数据,进行当前用车情景是否为该用车情景的判断,无需针对不同业务应用进行单独的情景开发,从而节省了车载系统的资源消耗,减少车载系统的资源浪费。
在本发明的一种实施例中,基于上述图1,如图2所示,上述业务应用130可以包括系统应用131以及多个第三方应用132,所述车载系统中还可以包括业务数据上报接口250;
所述业务数据上报接口250,可以用于接收系统应用按自身的预设上报时机,上报的预设通用格式的车身信号数据;以及接收各个第三方业务应用按各自的预设上报时机,分别上报的所述预设通用格式的第三方业务数据,将所述车身信号数据和第三方业务数据上报至所述数据中心。
在本发明的一种实施例中,所述数据中心110还可以用于基于预设的各个目标情景判断规则以及目标情景识别算法所需的业务数据,对所述各个业务应用上报的业务数据进行过滤处理,得到过滤后业务数据。
在本发明的一种实施例中,上述情景管理中心140还可以用于基于预设的用车情景与目标应用及目标操作的对应关系,确定与当前用车情景对应的至少一个第一目标业务应用及至少一个目标操作;
生成各个目标操作对应的操作指令,分别发送至各个第一目标业务应用,使得各个第一目标业务应用执行所述操作指令。
在本发明的一种实施例中,基于图1,如图3所示,上述车载系统中还可以包括:订阅接口350;
所述订阅接口350,可以用于各个业务应用向所述情景管理中心订阅用车情景;
因此,所述情景管理中心140还可以用于基于当前用车情景和各个业务应用预先订阅的用车情景,确定第二目标业务应用;将所述当前用车情景,下发到各个第二目标业务应用,以使各个第二目标业务应用,基于当前用车情景执行预设的业务操作。
关于上述车载系统中各部分具体的执行过程可以参见下面方法实施例部分的说明,此处暂不详述。
下面对本发明实施例提供的用车情景感知方法进行介绍。
本发明实施例提供的用车情景感知方法应用于车载系统,该车载系统可以包括多个业务应用。例如:可以应用于上述车载系统。
参见图4,图4是本发明实施例提供的用车情景感知方法的一种流程示意图,该方法具体可以包括以下步骤:
步骤S410,获得所述车载系统中各个业务应用上报的业务数据。
步骤S420,基于用车情景预设的目标情景判断规则中的参数值条件和所述业务数据,获得所需的第一目标业务数据;基于用车情景预设的目标情景识别算法所需的输入参数和所述业务数据,获得目标情景识别算法所需的第二目标业务数据。
步骤S430,将所述第一目标业务数据与用车情景预设的目标情景判断规则中的参数值条件进行匹配,获得是否为第一用车情景的判断结果;将所述第二目标业务数据输入至目标情景识别算法对应的情景判断模型中,获得所述情景判断模型输出的是否为第二用车情景的判断结果。
本发明实施例中,所述第一用车情景可以是业务边界明确的用车情景;所述第二用车情景可以是非业务边界明确的用车情景。
步骤S440,基于各个判断结果,确定当前用车情景。
本发明实施例提供的用车情景感知方法,首先获得各业务应用上报的业务数据,之后基于用车情景预设的目标情景判断规则中的参数值条件和上述业务数据,获得所需的第一目标业务数据,并基于用车情景预设的目标情景识别算法所需的输入参数和上述业务数据,获得目标情景识别算法需要的第二目标业务数据,将第一目标业务数据与预设的目标情景判断规则中的参数值条件进行匹配,得到是否为第一用车情景的判断结果,将第二目标业务数据输入至目标情景识别算法的情景判断模型中,来获得情景判断模型输出的是否为第二用车情景的判断结果,其中,第一用车情景为业务边界明确的用车情景,第二用车情景则是非业务边界明确的用车情景,之后基于各判断结果确定当前的用车情景。本发明实施例中,将各个业务应用的业务数据进行统一汇流,依靠统一的情景定义与情景感知计算,即可满足各业务应用的情景化业务拓展需求,无需针对各业务应用独立定义开发情景,节省了车载系统性能开销,从而减少车载系统资源的浪费。
在本实施例的用车情景感知方法应用于上述车载系统中的情况下,由于该车载系统可以包括数据中心,因此,本实施例中,各业务应用可以将自身业务数据上报至数据中心,由数据中心对各业务数据进行统一汇流与处理。
本发明实施例中,上述车载系统中的各个业务应用具体可以包括系统应用以及第三方应用。上述系统应用可以包括车身信号等等,上述第三方应用则可以包括导航、音乐应用、天气应用等等。
作为本发明实施例的一种具体实施方式,可以针对每个业务应用制定数据上报规范,对各业务应用进行业务数据细化。例如导航应用的业务数据可以包括导航开始和结束数据、地点围栏(车辆所处的地理区域)、拥堵预警数据、路段限速数据等等;天气应用的业务数据可以包括天气状态数据、高温预警数据等等;车身信号的业务数据可以包括车速、雨刮器、油量等等;音乐应用的业务数据则可以包括播放状态、歌曲信息、播放偏好等等。
本发明实施例中,上述数据上报规范可以是为各业务应用上报的数据制定统一的数据格式,如可以设置各业务上报的数据包括其数据编码ID、数据内容以及数据上报时机等等。上述数据编码ID可以包含应用的名称、版本信息以及业务名称等等,业务名称即具体业务数据的名称,如车速、雨刮器、油量等等。对于各业务数据来说,其数据编码ID是唯一的。业务数据的数据内容则可以包括数据的具体数值、数据类型、数据单位等等。各业务数据的上报时机则可基于实际应用中对不同业务数据的需求进行设置。例如,对于导航开始数据,可以指定其上报时机为实时上报;而对于车速、油量数据则可以变化上报;对于天气、车内空气质量等数据可以周期性上报;对于行驶状态等数据可以变化上报等等。
本发明实施例中,可以通过为各业务数据制定上报规范,来指定业务数据的数据编码、数据内容、上报时机,将各业务上报的各业务数据设置为通用的数据格式,可以提高后续数据获取、处理以及相应业务应用功能扩展的便利性。
因此,本发明实施例中,上述步骤S410可以具体包括以下步骤:
接收系统应用按自身的预设上报时机,上报的预设通用格式的车身信号数据;以及接收各个第三方业务应用按各自的预设上报时机,分别上报的所述预设通用格式的第三方业务数据。
如上所述,上述车载系统中可以包括业务数据上报接口,而各上报的各业务数据均有其自身业务数据编码ID,因此,作为本发明实施例的一种具体实施方式,该业务数据上报接口可以具备数据编码ID的订阅功能,来过滤冗余的业务数据。作为一种具体实施方式,可以是,在开发该业务数据上报接口时,预先定义各用车情景需要的业务数据的数据编码ID,在各业务进行数据上报时,业务数据上报接口则可以将预先定义的数据编码ID对应的数据进行上报,对于其他数据,则可以将其过滤,从而实现高效率地将情景感知计算所需的业务数据上报给数据中心。
作为本发明实施例的一种具体实施方式,上述业务数据上报接口可以通过Jar(Java Archive File)的方式提供给业务应用,进行低技术成本的集成使用。
参见图5,图5是本发明实施例中各业务应用进行数据上报的具体过程示意图:
如图5所示,业务应用可以包括导航、车身信号、天气等等,各业务应用上报的业务数据可以包含车身信号数据、导航上报的导航开始数据等等。其中,车身信号数据可以包括车速数据等,针对车速数据设定的上报规范可以是:设置车速数据的数据编码为Device_1_speed、数据类型为float浮点型、单位为km/h(千米每小时)、上报时机为变化上报。可以将上述数据上报规范下发至业务方(即业务应用),各业务应用则可以根据上述数据上报规范将业务数据通过数据上报接口(SDK Jar)上报至数据中心,进行后续的情景感知计算。
如上所述,本发明实施例中,在获取各业务数据后,即可分别针对各第一用车情景以及各第二用车情景,进行当前用车情景是否为该用车情景的计算。如上所述,上述车载系统中包含情景计算引擎,因此,本发明实施例中,可以是上述情景计算引擎来针对各第一用车情景以及各第二用车情景,进行当前用车情景是否为该用车情景的情景感知计算。
本发明实施例中,上述第一用车情景可以是指具有明确业务边界的用车情景,即只要业务数据满足预设的目标情景判断规则,就可以判断当前用车情景属于该用车情景,上述预设的目标情景判断规则可以是业务数据的需满足的参数值条件。
例如,上述第一用车情景可以包括雨天情景、高速情景等等,对于雨天情景来说,在检测到车辆行驶中、天气状态为雨天且雨刮器工作时就可判断当前情景属于雨天情景,上述车辆行驶中、天气状态为雨天且雨刮器工作就可以是雨天情景对应的目标情景判断规则包含的参数值条件。上述高速情景则可以是检测到车辆行驶中,并且行驶路段为高速路段,且车速超过预设阈值(如80km/h)时,就可判断当前情景属于高速情景,即车辆行驶中、行驶路段为高速路段且车速超过预设阈值(如80km/h)就可以是高速情景对应的目标情景判断规则中包含的参数值条件。
本发明实施例中,可以将上述第一用车情景对应的目标情景判断规则文本化,例如,上述雨天用车情景的目标情景判断规则可以是车速>0&&天气状态下雨&&雨刮器工作;油量报警情景的目标情景判断规则可以是车辆启动&&车速>0&&剩余油量/总油量<10%。
作为本发明实施例的一种具体实施方式,上述第一用车情景对应的预设目标情景判断规则中,可以包含各参数的数据编码ID,因此,可以基于各第一用车情景的目标情景判断规则中包含的参数的数据编码ID,从各业务应用上报的业务数据中获取所需的业务数据。
对于各业务边界明确的第一用车情景,在获得的所需的业务数据后,可以将各业务数据与其目标情景判断规则进行匹配,当业务数据的值与目标情景判断规则中的参数值条件一致时,就可判断当前用车情景属于对应的第一用车情景。
本发明实施例中,上述第二用车情景可以是指一些业务边界较为模糊的用车情景,即不可以对其设置明确的参数值条件,而是需要基于车辆的历史数据,使用训练好的模型进行是否为该用车情景的情景感知计算。
本发明实施例中,针对第二情景,可以使用预设的情景识别算法进行识别判断,上述情景识别算法可以是AI(Artificial Intelligence,人工智能)模型类算法(如智能神经网络算法),情景识别算法对应的情景判断模型可以是依靠云端的大数据进行训练得到。这类用车情景可以包括焦虑油量、周期性商圈购物、上班、回家等情景。开发人员可以针对各个不同第二用车情景设计不同的情景识别算法,来对相应情景进行识别。
例如,上述焦虑油量可以是:通常,汽车在出厂时,会预先设置一个油量报警的剩余油量值,如可以在剩余油量为满油量的5%时,在车辆控制屏幕、仪表盘等显示油量报警图标,来提醒用户加油。但在实际应用中,用户可能多次在油量剩余满油量的30%时就进行加油,那么就可以使用智能神经网络算法,基于用户加油行为以及加油时的剩余油量,对模型进行训练,从而判断出用户的焦虑油量可能是30%,因此,将油量信息输入预训练得到的模型,在剩余油量为满油量的30%时,可以判断当前用车情景是焦虑油量情景,相应的可以向用户发出提示消息,询问用户是否需要加油。
周期性商圈购物场景则可以是:用户可能会间隔固定的时间去往一个地点(记为A),那么就可以基于用户的出行标签以及出行时间训练模型,上述用户的出行标签可以是用车历史轨迹、驻车地理围栏,例如,若车辆分析出其停留地A地为购物中心,那么可以以A地的信息以及时间信息对模型进行训练,来得到用户的周期性购物情景判断模型,在将当前时间信息输入上述周期性购物情景判断模型,就可以识别当前情景是否为周期性购物情景,车辆则可以在当前情景为用户周期性购物的情景时,询问用户是否去A地,并可以给出用户当前所在位置到A地的路线、路况、A地的停车位等信息,当然还可以进一步地向用户显示A地周围的商家以及商家的消费活动等。
本发明实施例中,各目标情景识别算法的情景判断模型所需的目标业务数据可以是上述训练模型时使用到的输入参数(标签),例如,对于周期性购物情景来说,其所需的参数就可以是地点围栏、时间信息。
本发明实施例中,可以预先针对每个第二用车情景,定义该用车情景的目标情景识别算法的情景判断模型所需的业务数据的数据编码ID。因此,在判断当前用车情景是否属于各第二用车情景时,可以基于对应用车情景中的业务数据的数据编码ID,从已获得的业务数据中获取所需数据。
可见,本发明实施例中,通过基于判断规则进行判断以及使用目标识别算法进行情景计算,两种计算能力相互补充,使得感知计算的情景识别能力更加完善,提高用户的使用体验。
作为本发明实施例的一种具体实施方式,基于图4,如图6所示,在上述步骤S420之前,上述用车情景感知方法还可以包括:
步骤S620、基于预设的各个目标情景判断规则以及目标情景识别算法所需的业务数据,对所述各个业务应用上报的业务数据进行过滤处理,得到过滤后业务数据。
如上所述,本发明实施例中,可以通过为各业务数据制定数据上报规范,并使用业务数据上报接口对业务数据进行初步的过滤,得到各种情景感知计算需要用到的业务数据。另外,本发明实施例中还可以对重复以及非正常数据进行过滤。例如,若导航应用,持续上报导航开始数据,如在1分钟内上报10次导航开始数据,则该导航开始数据就是重复的、非正常的数据,因此,在上报一次导航开始数据后,对于后面的导航开始数据就可以进行过滤。
作为本发明实施例的一种具体实施方式,可以预先定义正常业务数据上报情况白名单,对于非业务数据上报情况白名单中的业务数据上报,则可以对其进行过滤,来为业务数据的融合提供稳定的数据支撑。具体的,可以是上述数据中心对各业务数据进行重复过滤、非正常过滤,来进一步剔除冗余数据。
因此,在本发明的一种实施例中,在对当前用车情景进行判断时,可以针对各第一用车情景以及各第二用车情景,从上述过滤后的业务数据中得到其所需的数据,进行相应的情景感知计算。
在本发明的一种实施例中,上述车载系统中还可以包括感知融合模块。在上述数据中心对上报的各业务数据进行处理之后,感知融合模块可以对各业务数据进行进一步的解析,具体的,可以是按照预设的时间批次对业务数据进行进一步解析,得到各业务数据的编码、类型、数值等信息,并基于上述信息构建统一的消费队列,并记录在系统缓存内。在使用情景计算引擎进行情景计算时,可以基于各目标情景判断规则以及各目标情景识别算法中包含的业务数据ID,从上述统一的消费队列中获取对应的业务数据。
如图7所示,图7是本发明实施例中进行数据处理的过程示意图:
导航、音乐、天气应用按照预设的数据上报规范,通过业务数据上报接口进行数据上报,业务数据上报接口可以对上报的业务数据进行按需订阅、剔除冗余,获取到各用车情景感知计算需要用到的业务数据,即对各业务数据进行数据汇流,数据中心则可以对过滤后的数据进行进一步的数据预处理,即对业务数据进行数据降噪以及流量管控(即过滤重复、异常数据),之后将处理后的数据发送至感知融合模块,由感知融合模块对上述业务数据构建出一个公共的消费队列。
本发明实施例中,通过对各业务数据进行剔除冗余、重复过滤、非正常过滤等,使得情景计算引擎可以直接获取各目标情景判断规则以及目标情景识别算法所需的业务数据,无需其对大量冗余数据进行计算,节省算力,从而进一步节省车载系统资源消耗。
作为本发明实施例的一种具体实施方式,可以针对各用车情景预先设置其对应的业务应用以及业务操作,这样,在确定当前的用车情景后,就可以确定与当前用车情景对应的目标业务应用以及目标操作,并生成相应的操作指令发送至对应的目标业务应用,以使目标业务应用执行相应的操作。
例如,针对上班通勤情景,可以设置当前用车情景属于上班通勤情景时,导航应用推荐查询当前位置到上班地点的路线路况信息、音乐应用推荐用户收听交通广播、桌面虚拟形象播放应用上班问候动画等等。
因此,如图8所示,图4中所示的方法还可以包括:
步骤S850,基于预设的用车情景与目标应用及目标操作的对应关系,确定与当前用车情景对应的至少一个第一目标业务应用及至少一个目标操作;
步骤S860,生成各个目标操作对应的操作指令,分别发送至各个第一目标业务应用,以使各个第一目标业务应用执行所述操作指令。
在确定当前用车情景所需的业务应用的业务功能后,即确定目标业务应用以及目标操作后,就可生成相应的操作指令。作为本发明实施例的一种具体实施方式,可以预先为各业务应用的业务功能设置业务功能编码(ID),该业务功能ID中可以包含业务功能名称、对应的业务应用的名称、版本号,对于每个业务功能来说,其业务功能编码是唯一的。因此,上述操作指令就可以包含各目标操作对应的目标业务功能ID,将操作指令发送至对应的各目标业务应用,就可以使各目标业务应用执行相应的目标业务功能。
参见图9a,图9a是本发明实施例中进行情景识别的过程示意图:
数据中心进行数据汇流后,感知融合模块可以对各业务数据进行感知融合,即针对各业务数据,构建一个统一的数据队列(即本发明实施例中的数据消费队列),图9a中列出的业务数据可以包括车速、行驶状态、地点围栏、天气状态、空调温度等。情景计算引擎则可以从数据队列中针对各情景判断规则以及各情景识别算法获取对应的目标业务数据(进行数据消费),分别进行规则计算(基于情景判断规则进行判断)以及人工智能计算(使用情景识别算法进行识别),从而对相应的情景进行识别。本例中,用车情景可以包括上班通勤情景、回家情景、油量报警情景、新能源电量报警情景、休息情景、高速情景、旅行情景、商圈购物情景等等。其中,上班通勤情景、回家情景、休息情景、旅行情景、商圈购物情景等情景,业务边界比较模糊,需要根据各个业务应用数据经目标情景识别算法才能得到当前用车情景,因此属于第二用车情景;油量报警情景、新能源电量报警情景、高速情景等情景,业务边界比较清晰,根据业务应用的数据经过预先设置的目标情景判断规则即可以直接确定当前用车情景,因此属于第一用车情景。
例如,上述上班通勤情景可以是,基于用户出行标签以及时间标签对模型进行训练,如,车辆多次在固定时间段由C地开往B地,并在B地停留一天,基于上述信息对模型进行训练,用训练出的模型基于当前时间(工作日上班时间段)、车辆行驶状态(车辆启动行驶)、车辆地理围栏(地点在C地附近),就可判断当前情景是否是上班通勤情景,即是否需要从C地开往B地,若是,音乐应用则可以推荐用户收听交通广播;导航应用可以推荐查询上班通勤路况;桌面虚拟形象播放应用上班问候动画等等。
与上班通勤情景类似,回家情景,也可基于用户出行标签以及时间标签对模型进行训练,如,车辆多次在固定时间段从B地开往C地,并在C地停留一晚,则可以基于上述信息对模型进行训练,用训练出的模型基于当前时间(工作日)、车辆所在位置(B地附近)以及车辆行驶状态(车辆启动行驶),判断当前情景是否是回家情景,若是,音乐应用则可以推荐用户收听交通广播;导航应用可以推荐查询回家路况。
休息情景则可以是基于车辆状态标签与地点围栏标签训练模型,例如,可以设计若车辆电源开启且车门未打开,并且车辆位置未发生变化,则可以判断当前情景属于休息情景,那么就可以打开音乐应用进行音乐播放,并可以打开氛围灯。当然,也可以设置若在车内检测到烟雾,则可以打开换气装置、车窗等。
油量报警情景可以是基于车辆行驶状态以及剩余油量判断当前情景是否为油量报警情景,该规则中的剩余油量可以是通过情景识别算法计算出的用户焦虑油量或预设的报警油量。例如,若情景识别算法计算出用户焦虑油量为满油量的30%,那么就可以在检测到车辆启动、车速大于0且剩余油量为满油量的30%时判断当前情景为油量报警情景。
新能源电量报警情景与上述油量报警情景类似,此处不再赘述。
上述各用车情景的训练方式以及包含的业务应用与操作仅为举例说明,本发明实施例中,对各用车情景的具体情况不做具体限定,各用车情景的具体训练方式以及包含的功能可以由开发人员根据实际应用进行不同设计。
如图9a所示,本发明实施例中可以针对各个用车情景建立用车情景汇总表,用以进行具体的情景识别。而如上所述,上述车载系统中还可以包括情景管理中心,因此,作为本发明实施例的一种具体实施方式,上述用车情景汇总表可以存储在情景管理中心中。
本发明实施例中,还可以对上述情景规则以及情景识别算法进行更新。参见图9b,作为本发明实施例的一种具体实施方式,可以通过情景云的远程运营来进行规则、算法模型的管理,并进行规则计算(即基于情景判断规则进行判断)和情景识别算法的更新,如,可以更新规则计算的规则(规则协议)以及情景识别算法的情景判断模型,规则的更新具体可以是更新上述规则文本,情景判断模型的更新可以包括算法的选择、特征选取以及模型输出选择等等,更新好之后就可以计算生效上述规则以及情景判断模型,完成情景计算引擎中规则计算与人工智能计算(情景识别算法)的更新。
本发明实施例中可以是通过热加载的方式完成算法的更新与生效。热加载即不重启一个项目,使得部分代码更新具体可以通过java类加载器实现。
通常,在实际的软件开发过程中,是先针对业务应用提出业务需求,再由开发人员进行相应的软硬件开发。例如,对于音乐应用,可能想根据不同的天气(雨天、雪天等等)为用户推荐不同的音乐,那么其就可能需要根据雨天情景、雪天情景的判断结果来进行不同的音乐推荐。
因此,在本发明的一种实施例中,基于图4,参见图10,上述步骤S440之后,还可以包括以下步骤:
步骤S1050、基于当前用车情景和各个业务应用预先订阅的用车情景,确定第二目标业务应用;
如上所述,上述车载系统中可以包括订阅接口,那么,各业务应用就可以根据自身的业务需求,通过该订阅接口订阅相应的用车情景。具体的,可以是业务应用在情景管理中心中的用车情景汇总表中查询是否有其所需的用车情景,并进行相应目标情景的订阅。
步骤S1060、将所述当前用车情景,下发到各个第二目标业务应用,以使各个第二目标业务应用,基于当前用车情景执行预设的业务操作。
情景计算引擎得到各情景判断结果,并由情景管理中心基于各情景判断结果得到目标用车情景后,即可按照各业务对用车情景的订阅情况,将订阅通知下发至订阅了目标用车情景的业务应用中,业务应用就可以执行相应的业务操作。
参见图11,图11为本发明实施例中进行用车情景输出的一种示意图:
如上所述,设置好用车情景后,可以为各用车情景设置用车情景汇总表,进行情景识别汇总,如图11所示,用车情景汇总表中可以包含的用车情景有上班通勤情景、回家情景、油量报警情景、新能源电量报警情景、休息情景、高速情景、旅行情景、商圈购物情景等等。各业务应用(导航、音乐等等)可以通过情景订阅接口(即本发明实施例中的订阅接口,是一种开发者平台接口)进行用车情景的订阅、查询。在情景感知计算得到结果后,并确定目标用车情景后,可以通过情景开放服务输出该场景,即通过情景订阅接口下发订阅通知至相应业务应用,使得业务应用执行对应的操作。
如图11所示,在建立情景汇总表时,可以为各情景制定数据规范,如可以包括为各情景设置情景编码ID、情景生成方式(第一用车情景或第二用车情景)、时间戳、原始数据、情景描述、情景的生命周期等等。上述时间戳可以指的是情景开始发生的时间,原始数据则可以包括情景需要用到的业务数据的数据编码ID,情景描述则可以包括一些功能描述,如数据ID与情景的对应关系描述、各业务功能的描述等等。生命周期则可以指的是情景开始到结束的时间段。因此,各业务应用就可根据情景包含的数据编码ID进行相应的情景订阅。
如图12所示,图12是本发明实施例中音乐应用订阅并执行雨天情景的一种过程示意图:
音乐应用可以通过情景订阅接口订阅雨天情景,若情景计算引擎识别出当前用车情景属于雨天情景,就可以向音乐应用发送订阅通知,音乐应用接收到订阅通知后,就可以进行歌曲推荐。具体的,可以是根据用户的历史数据向用户推荐雨天歌曲,并判断用户是否接受,作为一种具体实施方式,可以是用户点击推荐的歌曲则判断用户接受该推荐,就可播放歌曲。音乐应用可以根据用户对上述推荐音乐是否接受的情况进行偏好分析,以使得后续的音乐推荐更加准确。
本发明实施例中,各用车情景可以叠加,即同一时间段可以识别出多个用车情景。例如,用户在开车上班时,即上班通勤情景进行中时,若当前条件符合雨天情景以及高速情景,那么此时的用车情景就可以包括上班通勤情景、雨天情景以及高速情景,订阅这三个情景的业务应用就会收到相应的订阅通知,各业务应用则可以进行对应业务功能的执行。
作为本发明实施例的一种具体实施方式,可以为不同的用车情景设置不同的优先级,例如可以将与驾驶安全相关的用车情景的设置为高优先级的情景,如汽车故障情景、油量报警情景等。当一个用车情景正在发生时,若发生了优先级高于当前用车情景的情景,就可以中断当前用车情景,转去执行该优先级较高的情景,待优先级较高的情景结束后,再继续执行上述当前用车情景。例如,当前情景为回家情景,若此时故障情景出现,那么就可以中断回家情景,转去执行故障情景相关业务,如显示故障原因、显示最近维修点等等,当该故障情景结束后,再继续执行回家情景。
如图13所示,图13是本发明实施例中车载系统进行用车情景感知的流程示意图:
该车载系统可以分为情景感知计算层、接口层以及业务应用层。业务应用层的各个业务应用(导航、车身信号、音乐、天气等等)将自身业务数据上报至业务数据上报接口,业务数据上报接口将各情景需要的业务数据进行数据汇流,上传至数据中心,数据中心对各业务数据进行进一步的剔除冗余、过滤重复以及非正常的数据,并将处理后的数据发送至感知融合模块,由感知融合模块构建公共的消费队列,情景计算引擎主要包括规则计算以及情景识别算法(人工智能计算)两类算法,并由规则、算法模型管理负责其具体规则、模型更新,情景计算引擎可以从上述消费队列中获取各情景计算所需的业务数据进行情景感知计算,从情景管理中心中识别情景。各业务应用可以预先通过订阅接口,进行情景订阅、查询,根据情景管理中心中的用车情景汇总表订阅相应情景。当从情景管理中心中识别出用车情景后,即可通过情景开放服务输出情景,即通过订阅接口向相应的业务应用发送订阅通知,使得相应业务应用执行其功能。
可见,与现有技术中,融合部分系统开放的车身信号数据和自身业务数据,完成相对简单的情景感知,导致由于受业务所限,使得情景定义狭隘且不全面,对于复杂的情景感知能力匮乏。以及应用之间情景不相互开放共享,部分情景存在业务重叠、定义偏差、重复计算等问题,造成冗余开销,加重了整个车载系统算力消耗相比,本发明实施例中提供的用车情景感知方法,通过统筹感知车载系统车身信号以及各个应用的业务数据,形成数据汇流,数据可以通过端上轻量级计算引擎完成感知融合,识别出准确且全面的用车情景,在此基础上就可以面向整个系统内的应用输出情景。
另外,各个应用可以参考统一定义的用车情景识别汇总表,根据自身情景化业务拓展需求,按需订阅情景,也可以批量查询实时情景状态。
可见,本发明实施例中,各个应用方需将各自业务数据汇流到数据中心,依靠系统层面统一的情景定义、情景感知计算,情景输出,即可完成自身情景化业务拓展需求。各个应用免去了独立定义开发情景所需面对的种种问题,实现计算剥离,真正成为了数据融合的受益者。
从整体方面看,该方法进一步拓展了系统功能,丰富了平台接口(业务数据上报接口、订阅接口等等),形成了用车情景化的统一定义梳理,高效使用端上计算能力,以更合理的性能开销满足了车载系统各个应用情景化业务拓展需要。
本发明实施例还提供了一种电子设备,应用于车载系统,所述车载系统中安装有多个业务应用,如图14所示,包括处理器1401、通信接口1402、存储器1403和通信总线1404,其中,处理器1401,通信接口1402,存储器1403通过通信总线1404完成相互间的通信,
存储器1403,用于存放计算机程序;
处理器1401,用于执行存储器1403上所存放的程序时,实现如下步骤:
获得所述车载系统中各个业务应用上报的业务数据;
基于用车情景预设的目标情景判断规则中的参数值条件和所述业务数据,获得所需的第一目标业务数据;基于用车情景预设的目标情景识别算法所需的输入参数和所述业务数据,获得目标情景识别算法所需的第二目标业务数据;
将所述第一目标业务数据与用车情景预设的目标情景判断规则中的参数值条件进行匹配,获得是否为第一用车情景的判断结果;将所述第二目标业务数据输入至目标情景识别算法对应的情景判断模型中,获得所述情景判断模型输出的是否为第二用车情景的判断结果;其中,所述第一用车情景为业务边界明确的用车情景;所述第二用车情景为非业务边界明确的用车情景;
基于所述各个判断结果,确定当前用车情景。
上述电子设备提到的通信总线可以是外设部件互连标准(Peripheral ComponentInterconnect,PCI)总线或扩展工业标准结构(Extended Industry StandardArchitecture,EISA)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示,图中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。
通信接口用于上述电子设备与其他设备之间的通信。
存储器可以包括随机存取存储器(Random Access Memory,RAM),也可以包括非易失性存储器(Non-Volatile Memory,NVM),例如至少一个磁盘存储器。可选的,存储器还可以是至少一个位于远离前述处理器的存储装置。
上述的处理器可以是通用处理器,包括中央处理器(Central Processing Unit,CPU)、网络处理器(Network Processor,NP)等;还可以是数字信号处理器(Digital SignalProcessor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
在本发明提供的又一实施例中,还提供了一种计算机可读存储介质,该计算机可读存储介质内存储有计算机程序,所述计算机程序被处理器执行时实现上述任一用车情景的感知方法的步骤。
在本发明提供的又一实施例中,还提供了一种包含指令的计算机程序产品,当其在计算机上运行时,使得计算机执行上述实施例中任一用车情景的感知方法。
在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时,全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质,(例如,软盘、硬盘、磁带)、光介质(例如,DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。
需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
本说明书中的各个实施例均采用相关的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
以上所述仅为本发明的较佳实施例,并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等,均包含在本发明的保护范围内。