CN104767787A - 用于驾驶员通知处理的方法和设备 - Google Patents

Abstract

公开了一种用于驾驶员通知处理的方法和设备。一种系统包括被配置为从与车辆计算系统(VCS)进行通信的实体接收通知请求的处理器。所述处理器还被配置为接收通知内容和通知参数。所述处理器还被配置为验证所述实体的用于将通知显示在VCS上的权限。另外，所述处理器被配置为基于容许的内容来验证通知内容。所述处理器另外被配置为基于容许的参数来验证通知参数，并在成功验证权限、通知内容和通知参数之后使通知排队等候以进行显示。

Description

用于驾驶员通知处理的方法和设备

技术领域

示意性实施例总体上涉及一种用于驾驶员通知处理的方法和设备。

背景技术

在包括车辆计算系统的车辆中，车辆头部单元可向用户显示来自于嵌入式应用或技术的通知。该情况的一个示例可以是当驾驶员从连接的电话接收电话呼叫的时候。可通知车辆计算机该呼叫，可中断任何屏幕上的活动，并可将通知显示在头部单元上。

包括确认和/或取消消息的通知可能会使驾驶员分心，特别是在高驾驶员分心类型的情况下(例如，但不限于，高交通量、天气、转弯、车道变化等)。此外，在存在大量连接的装置的情况下，许多装置和/或应用可能正在尝试将消息发送到车辆系统，因此，可能需要按优先级来对消息进行排序的某种系统。

发明内容

在第一示意性实施例中，一种系统包括被配置为从与车辆计算系统(VCS)进行通信的实体接收通知请求的处理器。所述处理器还被配置为接收通知内容和通知参数。所述处理器还被配置为验证所述实体的用于将通知显示在VCS上的权限。另外，所述处理器被配置为基于容许的内容来验证通知内容。所述处理器另外被配置为基于容许的参数来验证通知参数，并在成功验证权限、通知内容和通知参数之后使通知排队等候以进行显示。

在第二示意性实施例中，一种计算机实现的方法包括：从与车辆计算系统(VCS)进行通信的实体接收通知请求。所述方法还包括：接收通知内容和通知参数。此外，所述方法包括：验证所述实体的用于将通知显示在VCS上的权限。所述方法另外包括：基于容许的内容来验证通知内容。另外，所述方法包括：基于容许的参数来验证通知参数，并在成功验证权限、通知内容和通知参数之后使通知排队等候以进行显示。

所述实体可包括雷达探测器。

所述实体可包括运行在远程装置上的应用。

容许的内容可包括特定类型的内容。

容许的内容可包括预定义情况下的特定类型的内容。

所述方法可包括：接收替换内容以替换被验证为无效的内容。

所述方法可包括：用基于接收到的替换内容产生的新通知来替换排队等候的通知。

所述方法还可包括：向所述实体报告被验证为无效的内容。

所述方法还可包括：用预定义通用参数来替换被验证为无效的参数。

在第三示意性实施例中，一种非暂时性计算机可读存储介质，其中，所述存储介质存储当由处理器运行时促使处理器执行包括以下步骤的方法的指令：从与车辆计算系统(VCS)进行通信的实体接收通知请求。所述方法还包括：接收通知内容和通知参数。此外，所述方法包括：验证所述实体的用于将通知显示在VCS上的权限。所述方法另外包括：基于容许的内容来验证通知内容。另外，所述方法包括：基于容许的参数来验证通知参数，并在成功验证权限、通知内容和通知参数之后使通知排队等候以进行显示。

附图说明

图1示出示意性车辆计算系统；

图2示出根据实施例的用于将一个或更多个所连接的装置与基于车辆的计算系统整合的系统的示例性块拓扑；

图3示出全局通知系统请求接收的示意性示例；

图4示出全局通知系统请求产生的示意性示例；

图5示出优先级调度处理的示意性示例。

具体实施方式

根据需要，在此公开本发明的详细实施例；然而，将理解的是，所公开的实施例仅仅是本发明的示例，本发明可以以各种可替代形式实施。附图无需按比例绘制；可夸大或最小化一些特征以示出特定组件的细节。因此，在此公开的具体结构和功能细节不应该被解释为限制，而仅仅作为用于教导本领域技术人员以各种方式利用本发明的代表性基础。

图1示出车辆31的基于车辆的计算系统(VCS)1的示例块拓扑。这种基于车辆的计算系统1的示例是由福特汽车公司制造的SYNC系统。设置有基于车辆的计算系统的车辆可包含位于车辆中的可视前端界面4。如果设置有例如触敏屏幕，则用户还能够与所述界面交互。在另一示意性实施例中，通过按钮按压、可听语音和语音合成来进行交互。

在图1中所示的示意性实施例1中，处理器3控制基于车辆的计算系统的操作中的至少某部分。设置在车辆内的处理器允许对命令和程序的车载处理。此外，处理器连接到非永久性存储器5和永久性存储器7两者。在该示意性实施例中，非永久性存储器是随机存取存储器(RAM)，而永久性存储器是硬盘驱动器(HDD)或闪存。

处理器还设置有允许用户与处理器进行交互的多个不同的输入。在该示意性实施例中，麦克风29、辅助输入25(用于输入33)、通用串行总线(USB)输入23、全球定位系统(GPS)输入24和蓝牙输入15均被提供。还设置有输入选择器51，以允许用户在各种输入之间进行交换。在对麦克风和辅助连接器两者的输入被传送到处理器之前，通过转换器27将所述输入从模拟转换为数字。虽然未示出，但是与VCS进行通信的很多车辆组件和辅助组件可使用车辆网络(诸如，但不限于控制器区域网络(CAN)总线)以向VCS(或其组件)传送数据并传送来自于VCS(或其组件)的数据。

对系统的输出可包括但不限于可视显示器4以及扬声器13或立体声系统输出。扬声器连接到放大器11并通过数模转换器9从处理器3接收其信号。还可分别沿19和21所示的双向数据流生成到远程蓝牙装置(诸如，个人导航装置(PND)54)或USB装置(诸如，车辆导航装置60)的输出。

在一示意性实施例中，系统1使用蓝牙收发器15与用户的移动装置53(例如，蜂窝电话、智能电话、个人数字助理(PDA)或具有无线远程网络连接能力的任何其它装置)进行通信17。移动装置随后可用于通过例如与蜂窝塔57的通信55来与车辆31外部的网络61进行通信59。在一些实施例中，蜂窝塔57可以是WiFi接入点。

移动装置和蓝牙收发器之间的示例性通信由信号14表示。

可通过按钮52或相似输入来指示对移动装置53与蓝牙收发器15进行配对。因此，中央处理器(CPU)被指示：车载蓝牙收发器将与移动装置中的蓝牙收发器进行配对。

可利用例如与移动装置53关联的数据计划、话上数据或双音多频(DTMF)音调在CPU 3和网络61之间传送数据。可选择地，可期望包括具有天线18的车载调制解调器63以便在CPU 3和网络61之间通过语音频带传送数据16。移动装置53随后可用于通过例如与蜂窝塔57的通信55来与车辆31外部的网络61进行通信59。在一些实施例中，调制解调器63可与蜂窝塔57建立通信20，以与网络61进行通信。作为非限制性示例，调制解调器63可以是USB蜂窝调制解调器，并且通信20可以是蜂窝通信。

在一示意性实施例中，处理器设置有包括与调制解调器应用软件进行通信的API的操作系统。调制解调器应用软件可访问蓝牙收发器上的嵌入式模块或固件，以完成与(诸如设置在移动装置里的)远程蓝牙收发器的无线通信。蓝牙是IEEE 802 PAN(个域网)协议的子集。IEEE 802 LAN(局域网)协议包括WiFi并且与IEEE 802 PAN具有相当多的交叉功能。两者都适合于车辆内的无线通信。可以在本领域使用的另一通信方式是自由空间光通信(诸如，红外数据协会(IrDA))和非标准化消费者红外(IR)协议。

在另一实施例中，移动装置53包括用于语音频带或宽带数据通信的调制解调器。在话上数据的实施例中，当移动装置的拥有者能够在数据正被传送的同时通过装置说话时，可实现已知为频分复用的技术。在其它时间，当拥有者没有使用装置时，数据传送可使用整个带宽(在一示例中是300Hz至3.4kHz)。虽然频分复用对于车辆与互联网之间的模拟蜂窝通信而言可能是常见的并且仍在使用，但其已经很大程度上被用于数字蜂窝通信的码分多址(CDMA)、时分多址(TDMA)、空分多址(SDMA)的混合体所替代。这些都是ITU IMT-2000(3G)兼容的标准，并且为静止或者行走的用户提供高达2mbs的数据速率以及为移动的车辆中的用户提供385kbs的数据速率。3G标准现在正被为车辆中的用户提供100mbs以及为静止的用户提供1gbs的IMT-Advanced(4G)所替代。如果用户拥有与移动装置关联的数据计划，则所述数据计划可允许宽带传输且系统可使用宽得多的带宽(加速数据传送)。在另一实施例中，移动装置53被安装到车辆31的蜂窝通信装置(未示出)所替代。在另一实施例中，ND 53可以是能够通过例如(而不限于)802.11g网络(即，WiFi)或WiMax网络进行通信的无线局域网(LAN)装置。

在一实施例中，传入数据可经由话上数据或数据计划穿过移动装置、穿过车载蓝牙收发器并进入车辆的内部处理器3。例如，在某些临时数据的情况下，数据可被存储在HDD或其它存储介质7上，直至不再需要所述数据的时候为止。

其它可与车辆接口连接的源包括：具有例如USB连接56和/或天线58的个人导航装置54、具有USB 62或其它连接的车辆导航装置60、车载GPS装置24、或者具有与网络61的连接性的远程导航系统(未示出)。USB是一类串行联网协议中的一种。IEEE 1394(火线)、EIA(电子工业协会)串行协议、IEEE 1284(Centronics端口)、S/PDIF(索尼/飞利浦数字互连格式)和USB-IF(USB应用者论坛)形成了装置-装置串行标准的骨干。多数协议可被实施为用于电通信或光通信。

此外，CPU能与各种其它的辅助装置65进行通信。这些装置可通过无线连接67或有线连接69来连接。辅助装置65可包括但不限于个人媒体播放器、无线医疗装置、便携式计算机等。

此外或可选择地，CPU可使用例如WiFi收发器71而连接到基于车辆的无线路由器73。这可允许CPU在本地路由器73的范围内连接到远程网络。

除了具有通过位于车辆中的车辆计算系统执行的示例性处理之外，在某些实施例中，还可以通过与车辆计算系统通信的计算系统来执行示例性处理。这样的系统可包括但不限于：无线装置(例如，但不限于移动电话)或者通过无线装置连接的远程计算系统(例如，但不限于服务器)。总体上，这些系统可被称为车辆相关计算系统(VACS)。在某些实施例中，VACS的特定组件可根据系统的特定实施方式而执行处理的特定部分。通过示例而并非限制的方式，如果处理具有与配对的无线装置发送或者接收信息的步骤，则很可能由于无线装置不会与自身进行信息的“发送和接收”，因此无线装置不执行该处理。本领域的普通技术人员将理解何时不适合对给定解决方案应用特定的VACS。在所有解决方案中，预期至少位于车辆自身内的车辆计算系统(VCS)能够执行示例性处理。

图2是用于将一个或更多个所连接的装置与基于车辆的计算系统1(VCS)整合的系统200的示例性块拓扑。CPU 3可与一个或更多个收发器进行通信。所述一个或更多个收发器能够用于有线通信和无线通信，以整合一个或更多个装置。为了促进整合，CPU 3可包括装置整合框架(device integrationframework)101，其中，装置整合框架101被配置为向所连接的装置提供各种服务。这些服务可包括所连接的装置和CPU 3之间的消息的传输路由、允许所连接的装置向用户提供警报的全局通知服务、允许对由CPU 3执行的应用和由所连接的装置执行的应用进行统一访问的应用启动和管理设施以及针对各种可能的车辆31目的地的感兴趣地点的位置和管理服务。

如上所述，VCS 1的CPU 3可被配置为与一个或更多个各种类型的移动装置53交互。移动装置53还可包括装置整合客户端组件103，以允许移动装置53利用由装置整合框架101提供的服务。

所述一个或更多个收发器可包括多端口连接器集线器102。多端口连接器集线器102可用于CPU 3与除移动装置53之外的其它类型的所连接的装置之间的交互。多端口连接器集线器102可经由各种总线和协议(诸如，经由USB)与CPU 3进行通信，并还可使用各种其它连接总线和协议(诸如，串行外围接口总线(SPI)、内部集成电路(I2C)和/或通用异步接收器/发送器(UART))与所连接的装置进行通信。多端口连接器集线器102还可执行由所连接的装置使用的协议与在多端口连接器集线器102和CPU 3之间使用的协议之间的通信协议转换和配合服务。所连接的装置可包括作为某些非限制性示例的雷达探测器104、全球定位接收器装置106和存储装置108。

每当处理、应用或装置请求使用车辆计算机的资源时，可能存在与另一请求重叠和/或驾驶员分心的可能性。例如，如果电话和雷达探测器两者同时希望向驾驶员发送消息，则其中的一个将需要被给予优先权，使得消息可被顺序地显示。此外，可能期望在高驾驶员分心的时间期间或仅在通常情况下，阻止某些消息、媒体和驾驶员互动请求。

因此，示意性实施例提供对通知的应对和处理。此外，实施例还提出用于对通知请求进行排序、确定请求的优先级、呈现/阻止请求以及其它请求处理的解决方案。当所连接的装置或应用发送请求时，应对处理将确定是否/何时可显示所请求的消息。此外，所述处理将确定哪些消息优先级高于其它消息，以防止对资源的同时尝试使用并优化向驾驶员的通知呈现。

图3示出全局通知系统请求接收的示意性示例。全局通知系统是用于请求处理的处理。在该示意性实施例中，它至少处理对使用车辆显示器的请求。

在该示意性示例中，全局通知服务被启动(201)。该服务将对到来的请求进行处理，并且在该示例中，从全局通知服务(或与所述服务交互/运行所述服务的处理器)的角度来示出对请求处理的处理。在该示例中，所述处理首先接收对使用驾驶员显示器的请求(例如，用于呈现通知的请求)(203)。

除了接收请求之外，所述处理还接收将向驾驶员显示的内容(205)。在一些情况下，所述处理将仅接收将向驾驶员呈现的文本。在这些简单情况下，全局通知服务可用来验证文本的可容许性并将文本格式化为统一的标准字体(如果合适/期望)。在其它情况下，所述请求可包括响应控制(确认/拒绝/等)、多媒体、原图等。除了验证这些请求的可容许性之外，全局通知服务还可拒绝某些被认为是不适合为驾驶员显示的内容(例如，因为它可能太分散注意力)。

所述处理还可接收与给定请求相关的一些数量的参数(207)。参数可包括例如所请求的优先级状态(紧急)、条件显示修改器(触发器)、主要/次要文本、可能的驾驶员行为、消息类别等。适当时可包括其它合适的参数。

一旦由所述处理接收到请求，则可分配消息ID(209)。该消息ID可用于识别消息、用于来自于请求实体的消息状态请求以及用于任何其它合适的目的，其中，可将消息ID发送回请求实体(211)。通过将ID与消息相关联，请求实体可容易地检查所请求的消息的状态。

在该示意性示例中，全局通知服务首先尝试验证请求实体在任何情况下使用通知服务的权限(213)。侵入性程序甚至是良性程序可能尝试在未经容许的情况下使用通知服务。由于通过通知可能使驾驶员分心，因此汽车制造商可对通知请求进行保护，并仅允许特定的预先批准的应用或功能调用或者依情况而定的请求使用通知服务。因此，全局通知服务可首先验证请求实体具有提供任何种类的通知的权限。

如果通知使用无效(215)，则所述处理可阻止通知(217)并通知应用(如果期望)通知已被阻止(219)。另一方面，如果容许了一般的通知使用，则全局通知服务可继续验证通知的内容(221)。

由于一些应用和处理可能尝试发送包含媒体请求或需要驾驶员响应的请求的通知，则根据驾驶员分心水平、应用容许权限和与所请求的通知相关的分心的一般程度，所述处理可能不会允许这些通知。驾驶员或汽车制造商通常可禁止包括例如超过三秒的视频的任何通知。或者可禁止任何包括视频的通知。可为内容设置任何合适的保护参数，并且内容分发也可以是有条件的(即，在某些时刻容许，而在其它时刻阻止)。

如果内容无效(223)，则所述处理可阻止无效的内容(诸如阻止视频，但容许文本)(225)。可向请求通知的应用通知：一些内容/所有内容被阻止(227)，以便给予请求实体重新提交更可能被容许的形式的通知。

最后，在该示例中，所述处理可验证与请求相关的所请求的参数(229)。例如，如果应用包括高度紧急的参数，则所述处理可验证发起请求的应用被容许提交高度紧急的请求，或者高度紧急的请求此时被容许(例如，更高优先级的应用可能已经在使用该权限提交高度紧急的通知，例如，天气应用或应急应用)。还可验证应用的其它参数，诸如，但不限于，被显示的次数、次要行为、显示条件等。

如果有任何参数无效(231)，则所述处理可分配默认参数来替代无效的参数(233)。例如，如果请求显示通知三次，但仅单次显示被容许，则所述处理可用单次显示替代请求的三次显示。还可分配其它合适的默认参数，所述默认参数或者按照一般的形式，或者专用于请求但被拒绝的参数。例如，所述处理可用“一般优先级”替代被拒绝的高优先级的请求，或者，在另一情况下，所述处理可根据向全局通知服务提供的设置来用“增大的优先级”代替被拒绝的高优先级的请求，其中，“增大的优先级”提供比普通优先级更高但比高优先级更低的优先级。

一旦所有内容和参数已被验证和/或修正，所述处理可使通知格式化使得可使用标准格式的通知(235)。在这种情况下，文本、图形和任何请求的响应被设置为标准格式。这可有助于使驾驶员分心最小化，原因是驾驶员不太可能搜索响应按钮或者被新形式的广告或通知过于分心。

如果存在任何优先级队列，则随后可将通知添加到这样的队列(237)。例如，可基于与请求相关的容许参数或基于当前待处理的通知来确定优先级。也可将特定的优先级给予特定类型的请求，例如，可对导航通知给予比更多一般通知高的优先级，并且甚至可将更高的优先级给予天气通知。

一旦特定通知是队列中的下一个(239)，所述处理将在该通知被全局通知服务容许的时候显示该通知(241)。在通知正在等待处理的同时，所述处理可检查是否有任何该通知先前被拒绝的因素已被重新提交以进行替换(243)。例如，如果视频被拒绝，则应用可发送静态图像来替代视频。在合适的验证之后，如果期望，则全局通知服务可用重新提交的更新后的通知来替换待处理的通知(245)。

图4示出全局通知系统请求产生的示意性示例。该处理从请求实体的角度示出通知请求的示例性形式。在该示意性示例中，请求实体首先产生通知(301)。基于特定应用产生的通知的种类，通知可以是例如，但不限于，天气报告、雷达报告、导航方向、新歌名称等。

一旦通知已在本地被格式化并被汇集，所述处理可请求使用全局通知服务(针对图3所讨论的)(303)。随后将格式化后的通知发送到通知服务(305)，并且可持续进行请求/发送，直到所述服务证实接收到请求为止(307)。

响应于接收到的请求，全局通知服务可将通知ID发送回请求实体(309)。本地实体可使用该ID来修改和/或追踪待处理的通知。该ID还可被包括在任何响应数据中，使得请求实体可将响应数据与合适的通知相关联。一旦已接收到该ID(311)，所述处理可等待“错误”或其它拒绝消息(313)。如果发现了任何错误或拒绝消息(315)，所述处理可采取适当的措施。

例如，可能会接收到拒绝所请求的通知的内容或参数的拒绝消息。可对被拒绝的内容或参数进行评估(317)，并且如果需要，则可对所述消息或参数进行重新格式化(319)。如果存在将被发送的任何替换物，则所述处理可替换无效的内容/参数(321)。可将替换标志包括在重新格式化后的通知请求中(323)，使得全局通知服务知道：所述处理正在请求将被重新格式化的当前已有通知。

如果不存在错误，或者如果不期望进行重新格式化，则所述处理可等待已向驾驶员显示了通知的响应(325)。一旦已接收到通知(327)，所述处理可退出(假设不需要次要操作，诸如，后续的通知或驾驶员响应)。如果通知还未被显示，则所述处理可使用ID来检查显示状态(例如，队列位置)(329)。如果提交了ID请求，则所述处理可接收当前的队列状态(331)，以在需要时由应用使用。

图5示出优先级调度处理的示意性示例。在该示意性示例中，驾驶员可指定特定类型的通知的优先级。例如，如果驾驶员具有与车辆计算机交互的天气应用、音乐应用以及雷达探测器，则驾驶员可能想要使来自于这些应用的通知的优先级个性化。

例如，驾驶员可能想要雷达具有最高的优先级(由于常常需要快速反应)，紧接着是恶劣天气预警，紧接着是新歌名称，紧接着是一般的天气更新。这些可能已基于例如先进先出(FIFO)被预先进行了排序。但驾驶员可能希望自定义这种排序。

因此，所述处理可从驾驶员接收对优先级排序的请求(401)。响应于该请求，可检索现有应用的列表(403)。这可以是所有应用的列表，或仅是曾提交了通知请求(这可被追踪)的应用的列表。在另一情况下，所述列表可基于与特定应用的名称不同的应用的类型(例如，交通、天气、娱乐等)。可使用用于呈现将被确定优先级的多个选项的任何合适的方式。

可按照当前的最大优先级对检索出的以期望的任何一种格式的列表进行排序。因此，例如，在以上示例中，可将比“娱乐应用”(诸如，音乐应用)高的优先级给予“环境”应用(诸如，天气和雷达)。可随后向驾驶员呈现排序后的列表(407)。

驾驶员可随后与列表交互以对选择进行重新排序，在该示例中，这将包括将新歌通知移动到一般的天气报告上方，以及使雷达的优先级高过恶劣天气报告(假设它们当前在一般的“环境”分类下被给予平等的地位)。一旦已接收到所有合适的改变(409)，所述处理可能需要验证所述改变(411)。

例如，如果驾驶员尝试将紧急警报移动到低优先级状态，则这可能不会被系统控制器(例如，汽车制造商)所容许。其它排序也可能在合适的情况下被禁止。如果重新排序有效(413)，则所述处理可存储新的优先级队列(419)。另一方面，如果重新排序无效，则所述处理可将无效的优先级移动回合适的位置(415)。例如，可将被移动到低位的优先级移动回最低容许位置(尽管没有必要移动回它的原始位置)。随后还可向驾驶员呈现新列表(417)，其中，新列表显示基于重新排序的“修正项”。随后还可存储该列表(如果需要则等候驾驶员确认)。

尽管以上描述了示例性实施例，但这些实施例并不意在描述本发明的所有可能的形式。相反，说明书中使用的文字是描述性而不是限制的文字，并且应理解，在不脱离本发明的精神和范围的情况下可进行各种改变。另外，可将各种实现的实施例的特征进行组合以形成本发明的进一步的实施例。

Claims (10)

1.一种系统，包括：

处理器，被配置为：

从与车辆计算系统进行通信的实体接收通知请求；

接收通知内容和通知参数；

验证所述实体将通知显示在车辆计算系统上的权限；

基于容许的内容来验证通知内容；

基于容许的参数来验证通知参数；

在成功验证权限、通知内容和通知参数之后使通知排队等候以进行显示。

2.如权利要求1所述的系统，其中，所述实体包括雷达探测器。

3.如权利要求1所述的系统，其中，所述实体包括运行在远程装置上的应用。

4.如权利要求1所述的系统，其中，容许的内容包括特定类型的内容。

5.如权利要求1所述的系统，其中，容许的内容包括预定义情况下的特定类型的内容。

6.如权利要求1所述的系统，其中，处理器还被配置为接收替换内容以替换被验证为无效的内容。

7.如权利要求6所述的系统，其中，处理器还被配置为用基于接收到的替换内容产生的新通知来替换排队等候的通知。

8.如权利要求1所述的系统，其中，处理器还被配置为基于接收到的通知请求和通知内容来产生根据预定义格式的通知。

9.如权利要求1所述的系统，其中，处理器还被配置为向所述实体报告被验证为无效的内容。

10.如权利要求1所述的系统，其中，处理器还被配置为用预定义通用参数来替换被验证为无效的参数。