具体实施方式
参考图1,根据示例性实现方式,机动车辆100(汽车、摩托车、卡车、船只、飞机等)包括随车携带的基于振动的诊断系统101,其目的在于基于所感测的振动确定将对车辆100所采取的矫正动作。以这种方式,诊断系统101包括至少一个振动传感器102,其目的在于感测连同车辆100的操作发生的振动(例如,振动模式)。构建诊断系统101的振动分析电路106,从而将“正常”振动从“非正常”振动中区分开来,其目的在于:1、识别所辨别的对应于问题的非正常振动,针对该问题已经确定矫正动作以修正/解决该问题;并且2、进一步识别何时振动为非正常的(但是未被辨别),以使得这些振动可以被进一步处理(如本文所公开的)以识别相应的问题。矫正动作包括解决维护问题的动作(例如,将车辆运送到经销商以便维修的动作),以及解决紧急安全担心的动作(例如,尽快将机动车辆开到路边并且停止驱动机动车辆的动作)。
更具体地,根据示例性实现方式,基于由振动传感器102提供的所感测的振动指示,如果检测到所辨别的非正常振动(其对应于紧急安全担心(轮胎即将破裂、横拉杆接近其失效点等)),振动分析电路106可以(作为示例,经由随车携带的显示器、警示灯或者声音报警)直接地警告机动车辆100的操作者,以使得操作者能够采取紧急的纠正动作(例如,涉及停止机动车辆的动作)。另外,正如本文进一步所公开的,根据示例性实施例,当检测到所辨别的非正常振动时,振动分析电路106可以使用远程布置的通信设施来向车辆所有者间接地传送不那么紧迫的消息(电子邮件、文本消息等等),其对应于不那么严重的维护问题(例如,需要更换雨刮器)。
随车携带的基于振动的诊断系统的潜在优势在于可以通知车辆操作者紧急安全问题,诸如轮胎开始损坏或者转向部件受到压力;以及对于不那么严重的问题,例如可以向车辆所有者发送关于车辆的整体性能的月报(将振动信息与可以由一个或多个车辆的其他诊断系统获取的其他信息耦合),诸如,车辆诊断报告。可以向经销商通知急需维护的问题,以使得一份提前通知(例如,具有打折服务优惠券的通知)可以被传送到机动车辆100的所有者,例如通知所有者车轮轴承开始损坏,并且在一定的英里数需要被修理。
车队操作者可以被传送跨其车队的高级分析的汇总信息,从而引导关于维护问题、车队表现以及(可能的话)甚至驾驶员表现的决策。例如,可以向原始设备制造商(OEM)发送关于车辆磨损和撕裂的高级分析信息的月度汇总,从而有助于评估保证责任、潜在召回、产品性能、寿命预期等。另外,一级汽车供应商也可以被传送这种信息。
参考图2,根据示例性实现方式,随车携带的诊断系统101可以为联网系统200的一部分,该联网系统200可用于为系统101补充通信以及振动分析。根据示例性实现方式,联网系统200包括数据中心204,其关于机动车辆100远程布置,并且可以使用许多不同通信结构(诸如蜂窝结构、有线结构、基于广域网(WAN)的结构、这种结构的组合等)中的一个与诊断系统101进行通信。尽管在图2中没有被描绘,但数据中心204可以充当中心网络集线器,以便为除所描绘的机动车辆100以外的一个或多个机动车辆促进通信以及振动分析。因此,根据一些实现方式,数据中心204可以充当中心网络集线器,例如用于由共同分享的制造商所提供的机动车辆100、属于相同的基于订户服务的机动车辆100等。
根据特定示例性实现方式,数据中心204可以执行一项或者多项如下功能:通知车辆所有者针对其车辆的维护问题;通知车队所有者、原始设备制造商(OEM)以及经销商针对其相关联车辆的修理和修理问题;接收和记录由机动车辆(诸如机动车辆100)收集的振动记录;分析从一类相似机动车辆(例如,具有相同制造、型号和年限的车辆)收集的振动记录,以识别共同的问题,并且将这些共同问题归属于相似的振动模式;并且将机动车辆的诊断系统101填充有链接到相关联的共同问题和矫正动作的振动模式。
更具体地,随车携带的诊断系统101可以将数据传送到数据中心204,该数据表示“非正常”振动记录。这些记录可以对应于所辨别的振动签名、或已经归属于相关联的问题的模式、以及已被捕捉以用于进一步分析(由于模式超过某种阈值(振动持续时间、幅度、频率等))的未辨别的振动模式。以这种方式,数据中心204可以包括接口206,其目的在于接收来自机动车辆的表示(已辨别和未辨别的)非正常振动记录的数据,如本文进一步公开的。
数据中心204包括分析电路208,其目的在于分析针对特定单独机动车辆的振动记录,以及分析跨相同分类的机动车辆(诸如像共享相同制造、型号和年限的机动车辆)的振动记录。分析电路208提供可以被用于通知机动车辆所有者维护需求并且预测潜在的保证和召回问题(其也可以被发送到原始设备制造商(OEM)、供应商、经销商、车队操作者等)的结果。
图3描绘了根据示例性实现方式的基于联网、基于振动的振动诊断系统300的更详细的示意图。通常,系统300包括数据中心350,或“网络集线器”,以及随车携带的振动诊断系统304(图3中所描绘的那个),其被布置在机动车辆100(图3中所描绘的那个)上,其目的在于感测在相关联车辆100的操作期间发生的振动,并且基于所感测的振动采取适当的动作。
对于这一示例,诊断系统304包括振动传感器308的网络,该振动传感器308被布置在机动车辆100上,其目的在于感测可以在车辆100的操作期间发生的振动。采用这种方式,振动传感器308可以以阵列的方式围绕机动车辆100空间分布,从而感测可以由机动车辆100的系统(诸如动力系统、驱动系统、转向控制系统、轮胎、排气系统等)产生的振动和振动模式。
通常,振动传感器308可以是被构造成感测振动并且提供指示所感测振动的信号的任何传感器,诸如地震检波器、加速度计、基于微机电系统(MEMS)的运动传感器等。要注意的是:尽管图3描绘了单个机动车辆100,但根据特定的实现方式,系统300可以包含一个或多个这种机动车辆100。
振动传感器308感测在机动车辆100的操作期间发生的振动,其目的在于允许诊断系统304识别某种振动模式或签名。诊断系统304将“正常”振动与“非正常”振动区分开。采用这种方式,根据示例性实现方式,诊断系统304包括实时振动分析(RTVA)引擎306,其与振动传感器308耦合,以用于识别表示潜在的安全担心和/或维护问题的振动签名或模式的目的。
根据示例性实现方式,RTVA引擎306将所感测的振动模式与对应于之前辨别的维护和/或安全问题(其存储在随机动车辆304携带的数据库310中)的振动模式相比较。根据特定实现方式,该比较可以涉及比较多个振动签名或模式(诸如振动幅度——时间轮廓线、谱能量、谱分布、频包络、幅度|——时间轮廓等)中的任何一个。基于该比较以及可能的其他信息(除振动以外的感测参数、所感测振动的空间位置、机动车辆100的车龄或里程等)的考虑,RTVA306确定所感测的振动模式是否与特定的问题和矫正动作对应。
在非正常振动被识别为维修问题而非紧急安全担心的早期指示符的情况下(例如由数据库310中存储的数据表示的),RTVA引擎306使用诊断系统304的事件警报模块314,以将表示相应振动记录的数据传送到远程布置的数据中心350,以使得模式可以被记录并且与关心任何潜在维护动作的车辆所有者的通信可以被做出(如果合适的话)。采用这种方式,事件警报模块314可以耦合到天线320,天线320经由网络结构330耦合到远程数据中心350。根据示例性实现方式,网络结构330可以例如是蜂窝结构、基于WAN的结构、基于因特网的构造或者这种结构的组合。数据中心350包括接口352,其接收表示这种振动记录的数据。
在传送对应于初始非正常振动模式的记录之后,根据一些实现方式,事件警报模块314可以向数据中心350发送每日更新的记录(其指示机动车辆100所进行的出行数和出行的持续时间),以及在这些出行的每一个期间是否感测到相关联的非正常振动模式的指示。如果若干天都没有感测到特定的振动模式(例如,基于非正常振动模式类型可配置的),RTVA引擎306可以向数据中心350发送指示振动问题已经被解决的记录。
要注意的是:任何非驾驶日不会生成记录。因此,根据一些实现方式,在下一个驾驶日时(在任何数量的非驾驶日之后),RTVA引擎306将指示除了正常日报之外的非驾驶日的数量的记录传送到数据中心350。根据一些实现方式,在车辆在下一天启动时,RTVA 306传送前一天的记录,因为RTVA 306不知道:针对该天的机动车辆100,哪次出行是最后一次出行。
在将非正常振动模式识别为紧急安全问题(例如,车胎开始损坏或者横拉杆即将失效)的情况下,RTVA引擎306使用事件警报模块314来经由车辆304的显示器322(作为示例)立即并且直接地警告机动车辆100的操作者,以使得操作者可以采取紧急动作来防止另外的危险情况。例如,显示器322可以是机动车辆304内的随车携带显示器,诸如,发光二极管(LED)屏幕或者显示器。可以由其他报警设备(其例如提供可听到的和/或视觉报警)提供警报。另外,如在不是紧急担心的维护问题的情况下,RTVA引擎306还可以使用事件警报模块314,其目的在于将所识别的安全问题和相关联的振动记录以及其他信息传送到数据中心350,以使得数据中心350可以使用较少的直接通信(电子邮件、文本、自动生成的信件、统计报告等)警告所有者372、经销商376和潜在的其他374(OEM车队经理等)团体。
根据一些实现方式,数据中心350可以包括如下部件来进一步分析由事件警报模块314提供的数据,以及由其他机动车辆100的事件警报模块314提供的信息。通常来讲,数据中心350可以包括预测分析系统(PAS)引擎354,其执行关于振动记录的高级分析,所述振动记录已经被链接到特定的问题/矫正动作,其目的在于适应性学习哪些振动模式与哪些问题对应。PAS引擎354可以利用由相对大量的机动车辆100提供的相对大量的振动记录数据,以及可以从在线经销商维护记录收集的信息。
采用这种方式,根据一些实现方式,PAS引擎354耦合到数据中心350的经销商接口364,其(例如,经由网络结构370)与用于给定机动车辆100的适当经销商376通信,其目的在于将振动记录与用于机动车辆100的维护记录(例如,单独通过机动车辆100的唯一车辆识别码或VIN识别)相关。根据特定实现方式,网络结构370可以是基于蜂窝的结构、基于英特网的结构、基于WAN的结构等,这取决于特定的实现方式。由PAS引擎354执行的相关可用于学习新的和/或未知的振动模式的根本原因。采用这种方式,通过将例如相同制造/型号/年限的车辆的实际维护记录与从这些车辆获得的振动记录相关,PAS引擎354可以学习到某些振动模式与某些问题高度相关。
例如,相同制造/型号/年限的机动车辆可以各自经历由于消声器支架失效引起的类似振动模式。尽管那时不可归属于特定辨别的振动模式,用于这些机动车辆中的每一个的RTVA引擎306可以确定振动模式为非正常(即,超过用于认定模式为非正常的某些阈值),并且可以将相应的振动记录传送到数据中心350。PAS引擎354可以检查经销商维护记录,并且确定经历所述振动模式的车辆与被带来以便修理消声器支架的车辆存在重大的相关。
此外,基于经销商维护记录以及由机动车辆100的事件警报模块314传送的日志,PAS引擎354可以确定已经修理其消声器支架的机动车辆300的振动模式消失。对于本示例,基于其分析,PAS引擎354可以将振动模式识别为用于消声器支架的维护的指示符。因此,PAS引擎354可以用相应的振动记录填充具有相同制造/型号/年限的所有机动车辆100的数据库,所述振动记录例如识别指示问题的振动模式、所识别问题的描述以及相应矫正动作的描述。
根据示例性实现方式,出于更新的目的,最新学习到的振动模式(即,已经与某些问题相关的振动模式)可以存储在数据中心350的数据库356中;并且新学习到的模式可以被传送到机动车辆100,以使得新学习到的模式可以被这些机动车辆100的RTVA引擎306使用,其目的在于基于这些振动模式识别问题(以及相应的矫正动作)。采用这种方式,根据一些实现方式,机动车辆100包括新模式更新器模块324,其接收表示这种新学习到的振动模式的记录的数据,并且将这些记录存储在机动车辆的数据库310中。根据一些实现方式,所述更新可以作为月度更新的一部分被传送。
根据一些实现方式,数据中心350还可以包括报告生成器360,其产生月度车辆状况报告,该报告可以被传送(例如,发送电子邮件)到车辆所有者372以指示已经查看到的任何问题并且推荐任何维护问题或“观察”通知。根据一些实现方式,这些信息可以与通过类似基于OEM诊断的系统(诸如,发送给订户的车辆诊断电子邮件)发送的消息组合。在进一步的实现方式中,如果所有者372不是或者类似服务的订户,则PAS引擎354可以将电子邮件直接传送到所有者372。因此,预期到许多实现方式,该实现方式在所附权利要求的范围内。
根据一些实现方式,PAS引擎354将跨车辆制造/型号/年限的信息相关,以将早期警示提供到潜在保证或召回问题的OEM。类似的服务可以被提供到车队所有者,诸如租赁公司或者企业车队所有者。一级汽车供应商也可以从PAS引擎354接收关于其每个制造/型号内的主要系统的性能的信息,从而也提供潜在保证和召回问题的早期警示。例如,一级汽车供应商被可以通过PAS引擎354传送指示跨某种制造/型号的型号年份的转向部件的性能具有维护或安全问题的信息。
因此,总之,参考图4,根据示例性实现方式,技术400包括感测(框402)机动车辆中的振动并且分析(框404)所感测的振动。基于该分析,依照框406,选择性地生成对机动车辆所采取的矫正动作的指示。
依照图5的技术500,将振动模式归属于用于机动车辆的特定矫正动作可能发生。技术500包括接收表示机动车辆上所感测的振动模式的数据(框502),并且接收表示用于车辆的维护记录的数据(框503)。技术500包括至少部分地基于振动模式和维护记录归属用于机动车辆的矫正动作(框504)。
返回参考图3,根据示例性实现方式,随车携带的诊断系统304以及数据中心350均为物理机器,该物理机器由真实的硬件和软件组成。在这一点上,根据一些实现方式,可以采用图6中所描绘的物理机器。该物理机器600包括一个或多个中央处理单元(CPU)604,其执行存储在存储器606中的机器可执行指令608。存储器606可以是非暂时性存储介质,诸如基于半导体的存储器、基于磁性的存储器、光学存储器、可移除介质、这种介质的组合等,这取决于特定的实现方式。
当机器可执行指令608由CPU 604执行时,可以使CPU 604形成一个或多个图3中所描绘的引擎/模块,诸如RTVA引擎306、事件警报模块314、新模式更新模块324、报告生成器360、PAS引擎354等。除了CPU 604之外,物理机器600还可以包括其他硬件,诸如网络接口610、蜂窝接口612、显示器614等。要注意的是:尽管物理机器600在图6中被描述为包含在箱子(或机架)中,但机器600可采用分布式架构(诸如,用于数据中心350),其中机器600包括在多于一个位置处的设备。
尽管文本已经公开了有限数量的示例,但受益于本公开的本领域技术人员将从其中认识到众多的修改和变化。旨在所附权利要求覆盖所有这种修改和变化。