使用音频信号的车辆故障自动检测的制作方法

背景技术：

机动车可以是具有随时间能够磨损和损坏的许多运动部件的复杂机械。如果足够早地发现，预防(preemptory)措施可以潜在降低维修成本并延长使用寿命。在常规系统中，车辆中的电子控制系统典型地依赖于传感器阵列来测量发动机和其他系统的工作参数。这些常规传感器中的一些可以包括发动机温度传感器、油压传感器、油温传感器、冷却液温度传感器、氧气传感器、胎压传感器等。一般地，常规的传感器仅在问题发生之后检测到该问题，因为这种故障模式导致传感器检测标称外信号。因此，发动机故障(或任意车辆系统故障)可以随时随地发生，且驾驶员一般不能有利地知道故障即将发生以相应地采取正确动作和计划。此外，一些诊断太复杂或难以使用常规传感器读数。在一些情况中，某些故障模式或损坏状态甚至使用常规传感器技术完全检测不到。需要更好的方法和系统来在故障模式发生之前检测并诊断车辆问题。

技术实现要素：

在某些实施方式中，用于确定车辆故障的计算机实施的方法可以包括：处理器从设置在车辆上的至少一个麦克风接收音频数据，该音频数据对应于车辆产生的声音；处理器将该音频数据输入到具有训练模型的分析模块，该训练模型将各种音频数据与相对应的车辆故障情况相关联；以及处理器从分析模块得到基于音频数据的假定车辆故障情况。

在一些实施方式中，该方法还可以包括处理器将传感器数据输入到具有训练模型的分析模块，该传感器数据来自设置在车辆上的至少一个传感器，其中训练模型还将各种传感器数据连同各种音频声音与相对应的车辆故障情况相关联，以及其中从分析模块得到的假定车辆故障情况可以基于该音频数据和传感器数据。在一些情况中，传感器数据可以对应于至少一个车辆性能特性且训练模型可以通过机器学习被训练。

在某些实施方式中，该方法还可以包括处理器接收对应于车辆的当前位置的全球定位系统(gps)数据，其中从分析模块得到的假定的车辆故障情况基于音频数据和gps数据。在进一步的实施方式中，该方法可以包括处理器接收对应于车辆的当前位置的附近的交通的交通数据，其中从分析模块得到的假定的车辆故障情况基于音频数据和交通数据。在一些实施中，各种音频数据和对应的车辆故障情况可以被存储并从数据库获取，且接收的音频数据可以被添加到数据库中的各种音频数据和对应的车辆故障情况。

在一些实施方式中，系统可以包括一个或多个处理器，以及一个或多个非暂态计算机可读存储介质，其包含指令，被配置成使得一个或多个处理器执行操作，该操作包括：处理器从设置在车辆上的至少一个麦克风接收音频数据，该音频数据对应于车辆产生的声音；处理器将该音频数据输入到具有训练模型的分析模块，该训练模型将各种音频数据和相对应的车辆故障情况相关联；以及处理器从分析模块得到基于该音频数据的假定车辆故障情况。

在某些实施方式中，该系统还可以包括指令，被配置成使得一个或多个处理器执行操作，该操作包括处理器将传感器数据输入到具有训练模型的分析模块，该传感器数据来自设置在车辆上的至少一个传感器，其中训练模型还将各种传感器数据连同各种音频声音与相对应的车辆故障情况相关联，以及其中从分析模块得到的假定车辆故障情况可以基于音频数据和传感器数据。在一些情况中，传感器数据可以对应于至少一个车辆性能特性，以及序列模型可以通过机器学习来训练。

在进一步实施方式中，该系统可以包括指令，被配置成使得一个或多个处理器执行操作，该操作包括处理器接收对应于车辆当前位置的gps数据，其中从分析模块得到的假定车辆故障情况基于该音频数据和gps数据。

在一些实施方式中，该系统还可以包括指令，被配置成使得一个或多个处理器执行操作，该操作包括处理器接收对应于车辆当前位置附近的交通的交通数据，其中从分析模块得到的假定车辆故障情况可以基于音频数据和交通数据。在一些实施中，各种音频数据和对应的车辆故障情况可以被存储并从数据库获取，以及接收的音频数据可以被添加到数据库中的各种音频数据和对应的车辆故障情况。

在进一步实施方式中，用于确定车辆故障的系统可以包括：用于从设置在车辆上的至少一个麦克风接收音频数据的装置，该音频数据对应于车辆产生的声音；用于将音频数据输入到具有训练模型的分析模块的装置，该训练模型将各种音频数据与对应的车辆故障情况相关联；以及用于从分析模块得到基于音频数据的假定车辆故障情况的装置。

在某些实施中，该系统还可以包括用于将传感器数据输入到具有训练模块的分析模块的装置，该传感器数据来自设置在车辆上的至少一个传感器，其中训练模型还可以将各种传感器数据连同各种音频声音与对应的车辆故障情况相关联，以及其中从分析模块得到的假定车辆故障情况可以基于音频数据和传感器数据。传感器数据可以对应于至少一个车辆性能特性且训练模型可以通过机器学习训练。该系统还可以包括用于接收对应于车辆当前位置的gps数据的装置，其中从分析模块得到的假定车辆故障情况可以基于音频数据和gps数据。在一些情况中，该系统还可以包括用于接收对应于车辆当前位置附近的交通的交通数据的装置，其中从分析模块得到的假定车辆故障情况可以基于音频数据和交通数据。

附图说明

参考附图进行详细描述。

图1示出了包括随时间快要故障的的常见车辆系统的车辆车盘的简化图；

图2示出了根据某些实施方式位于声源周围的麦克风阵列的简化图；

图3示出了根据某些实施方式的多麦克风阵列的音频记录的曲线图；

图4示出了根据某些实施方式的使用音频信号自动检测车辆故障的系统的简化框图；

图5示出了根据某些实施方式的使用音频信号、传感器数据和环境数据自动检测车辆故障的系统的简化框图；

图6是示出了根据某些实施方式的来自车辆上的麦克风的音频信号与来自方向盘的传感器测量的相关的曲线；

图7示出了根据某些实施方式的包括全包含系统和车辆的使用音频信号自动检测车辆故障的系统的简化框图；

图8示出了根据某些实施方式的包括多个与云通信耦合的车辆的使用音频信号自动检测车辆故障的系统的简化框图；

图9示出了根据某些实施方式的使用音频信号自动检测车辆故障的简化流程图；

图10示出了根据某些实施方式的使用音频信号自动检测车辆故障的简化流程图；

图11示出了根据某些实施方式的使用音频信号执行自动检测车辆故障的某些方面的计算机系统的简化框图。

具体实施方式

本公开的方面一般涉及车辆系统，且特别地涉及根据某些实施方式的使用音频信号和机器学习算法自动检测车辆故障的系统和方法。

在以下描述中，将描述车辆系统的各种实施方式。出于解释目的，提出了特定的配置和细节以提供对实施方式的全面理解。但是，本领域技术人员也明白的是可以不用特定的细节来实施实施方式。此外，公知特征被省略或简化以不模糊描述的实施方式。

音频特征可以是车辆工作状态的很好的指示器。例如，一些音频特征可以指示令人满意的性能，而其他音频特征可以指示部件故障或故障正在发生(例如过度磨损的刹车片或刹车盘)。在一些实施方式中，麦克风(即，传感器)阵列被设置在车辆的内部和/或外部周围。处理器控制的机器学习算法可以用于确定随时间车辆的“正常”运行状态是什么。如果传感器检测到稍微异常或短暂(即不协调)的音频特征，其可以提前提醒驾驶员(或处理逻辑)这种情况并可以交叉参考可能问题的数据库以诊断这种异常最可能的原因。此外，麦克风阵列可以用于三边测量存在问题的音频特征的精确位置。因此，可以执行预防措施和服务(修理)以潜在避免否则会发生的花费大的修理或灾难性故障。

图1示出了包括可能随时间易于故障的常见车辆系统的车辆100的车盘的简化图。车辆100包括车轮部件110、悬挂系统120、转向控制系统130、推进系统140以及排气系统150。这里示出和论述的系统不是限制性的；其他系统或子系统(例如，燃料管路、充电系统、电池组、电子控制系统等)也可以存在可以根据本公开使用音频信号被检测的故障机构，这可以是本领域技术人员所理解的。

车轮部件110可以包括轮缘、轮胎或与车轮相关联的其他特征。可以指示部件故障或部件故障正在发生的一些音频特征可以包括胎扁平或溃气、刹车磨损、由于四轮定位或车轮平衡问题导致的轮胎花纹不均衡等，每一个具有对应的音频特征。

悬挂系统120可以包括震动件、支杆、卷簧、板簧、扭力梁等。指示悬挂系统中的部件故障或故障正在发生的一些音频特征可以包括刺耳的噪音、摩擦声或在发生故障的悬挂系统中常发生的其他噪声，每个具有对应的音频特征。

转向控制系统130与转向车辆100相关联并可以包括齿轮齿条系统、轴、拉杆、转向臂等，每一个具有对应的音频特征。指示转向控制系统中的部件故障或故障正在发生的一些音频特征可以包括刺耳的噪音、摩擦声或在发生故障的转向控制系统中常发生的其他噪声

推进系统140可以包括与推动车辆相关联的系统，例如发动机组、启动系统、交流机、冷却系统、燃料系统、电池系统(例如，设计用于电动车的锂离子电池、电池冷却系统、防火电池)等，每个具有对应的音频特征。指示发动机中的部件故障或故障正在发生的一些音频特征可以包括刺耳的噪声(例如皮带)、咔嚓声(例如启动电机)、砰砰声(例如发动机组)或在某些种类的推进系统中常发生的其他噪声。推进系统140可以是内燃机、电动机、混合动力发电机(例如，内燃机和电机)、基于氢燃料电池的电动机或可以给车辆提供动力的任意合适的设备。

排气系统150可以包括废气歧管、尾管、催化转化器等，每个具有对应的音频特征。指示排气系统中的部件故障或故障正在发生的一些音频特征可以包括异常大的排气声、金属撞击声(例如，排气系统松动)或与故障排气系统相关联的常见的其他噪声，这些是本领域技术人员所理解的。

车辆100可以是任意合适的车辆，包括乘用车(例如，小汽车、皮卡、摩托车等)、商用车(例如，卡车、牵引车、半卡车、重型器械)等，以及任意类型(例如，电动车、内燃机车、柴油车、混合动力车、燃料电池车等)。

音频源位置检测

图2示出了根据某些实施方式的位于音频源210周围的麦克风阵列m1-m3的简化图200。使用设置在关于音频源的不同位置的多个麦克风可以改善记录的保真度并使用音频相位和/或定时分析提供音频位置能力，这在下面进一步描述。参考图2，音频源210发射音频信号220，其被麦克风m1-m3获取。麦克风m1距离音频源210的距离l1，麦克风m2距离音频源210的距离l2，以及麦克风m3距离音频源210的距离l3。每个麦克风m1-m3可以被设置在关于音频源210的不同位置。如在图2中绘制的示例中所示，m1是距离音频源210最近的且m2是距离最远的。每个麦克风m1-m3可以依据其关于音频源210的相对位置在不同的时间接收音频信号220(即音频数据)。这些时间差可以被计算(即，计算为相位差)，其可以用于确定音频源210的位置，例如通过三边测量，这是本领域技术人员所理解的。

虽然为了图示简明，图2示出了三个麦克风m3，但是根据本公开的某些实施方式多于三个麦克风可以用于音频源定位。具体地，三个麦克风可以允许在平面内确定音频源的2维(2d)位置。但是，通过将麦克风的数量增加到四个或更多麦克风，可以确定立体空间(例如车辆的内箱)的音频源的3维(3d)位置。这不仅可以识别音频源的水平2d位置(例如x和y位置)，而且可以识别其垂直高度(例如z位置)。根据一些实施方式，添加垂直高度位置可以促进更精细和准确的扬声器识别和/或隔离，因为乘客不仅可以通过他们通常地坐在车里中的位置来区分，而且可以通过他们在所坐的位置时的身体高度来区分。

图3示出了根据某些实施方式的多麦克风阵列的音频记录的曲线图300。回到简单的三麦克风示例，曲线图300示出了如图2所示的麦克风m1-m3的每一个接收的音频数据的幅度相对时间的曲线。麦克风m1在时间t1开始接收音频信号220，麦克风m2在时间t2开始接收音频信号220，以及麦克风m3在时间t3开始接收音频信号220。如上所述，接收的信号之间的时间差(例如，δm1-m2,δm1-m3,δm2-m3)可以用于使用常规的三边测量技术确定音频源210的位置，该技术包括到达时间差(tdoa)、音频信号之间的互相关函数，以及几何原理，这些是本领域技术人员所理解的。

使用音频信号的车辆故障的自动检测

图4示出了根据某些实施方式的使用音频信号自动检测车辆故障的系统400的简化框图。系统400可以包括车辆410，两个或更多麦克风(n1-n4)，模拟数字转换器(a/d)430、一个或多个微处理器440、逻辑450(即，存储器中存储的软件)、数据库460以及显示器470。系统框430、450、460和麦克风n1-n4的每一个可以与处理器440电通信。可以理解虽然图4包括示出看似在平面中排列的麦克风n1-n4的“俯视”图，但是实际上麦克风n1-n4可以被安装在不同的垂直高度以得到音频源的3-d位置。

车辆410可以包括任意类型的车辆(例如，乘用车、商用车等)。麦克风n1-n4可以被设置在车辆410的车盘周围以检测车辆声音(即，正常和异常工作声音)，包括但不限于，以上参考图1描述的各种系统。在一些实施方式中，麦克风n1-n4可以被设置在车辆410的车厢内(但是靠近车盘)，在车盘上(例如，暴露给元件，之间的位置，或其任意组合。麦克风n1-n4可以是任意合适类型的麦克风，包括动态或电容(condenser)麦克风(其他类型，包括带状、碳、压电、光纤、激光、液体、mems等)。一些实施方式可以使用全向麦克风来检测来自车辆410的任意部分的声音。在一些实施中，定向麦克风可以用于某些应用(例如，特定系统的聚焦音频记录)。任意多个麦克风可以在系统400中被使用。在一些实施方式中，麦克风n1-n4可以被伺服控制以在方向上改变其音频聚焦。一些麦克风可以是可调节的以在全向和定向聚焦之间切换。参考图4，麦克风n1-n4被安装在车辆410的车盘上(例如，在车架上)。但是，麦克风可以被安装在任意合适的位置。来自特定音频源的车辆声音可以被称为音频信号或音频特征。收集的接收的音频(即从多个音频源接收的，包括白噪声)一般可以被称为音频数据。

a/d430可以将模拟信号转换成数据信号以给送到处理器440用于计算分析。音频信号可以通常是具有模拟属性(例如，幅度、频率和/或时间分量)的波形文件。在一些实施方式中，a/d操作可以被集成到系统400的一个或多个其他组件(例如处理器440)。a/d使用和实现可以是本领域技术人员所理解的。

在一些实施方式中，处理器440可以包括一个或多个微处理器(μc)并可以控制软件的执行(例如，逻辑、数据库管理、接入和获取)、控制以及系统400的各种电部件之间的通信。在一些情况中，处理器440可以包括一个或多个微控制器(mcu)、数字信号传感器(dsp)等，具有支持硬件和/或固件(例如，存储器、可编程i/o等)，这些可以是本领域技术人员所理解的。

显示器470可以使用任意合适的图像生成技术来显示图像、消息、警示灯，例如阴极射线管(crt)、液晶显示器(lcd)、发光二极管(led)，包括有机发光二极管(oled)、投影系统等。例如，当检测到异常音频特征时，与数据库460相互参考，并识别(如下面进一步描述的)，消息可以被发送到显示器470以提醒驾驶员故障模式以发生或可能要发生。

逻辑450可以用软件、固件、硬件或其组合来实施，以分析从麦克风n1-n4接收的音频数据。如上所述，在一些实施方式中，逻辑450可以基于从每个麦克风接收的音频数据之间的相位差来计算音频源的位置。逻辑450还可以用于分析和确定音频数据的音频特性，包括幅度、频率和/或相位内容(例如定时数据)，隔离多个音频源，实时和后处理以过滤或改善音频数据的保真度，将音频数据与数据库460中存储的数据进行比较(下面所述)等。在一些实施方式中，如果某些音频信号基本是共模信号(即，它们之间基本没有相位差)，则逻辑450可以过滤或减弱该音频信号。

在一些实施中，逻辑450可以控制麦克风n1-n4的一个或多个的朝向或聚焦(例如经由伺服控制)以用于标定位置的音频接收。可替换地或附加地，逻辑450可以控制与一个或多个麦克风n1-n4相关联的放大器设置以实现音频信号波束成形，由此实现标定位置的音频接收。例如，当逻辑450确定某音频源在特定位置(例如右前支杆)时，麦克风n1-n4可以被调节以聚焦对来自该指定位置的声波的接收的音频感测并抑制来自其他地方的声波的接收。这种标定位置的音频接收促进改善的保真度(例如更好的信噪(s/n)比，更好的信干(s/i)比，等等)。

在一些实施方式中，逻辑450可以使用学习算法以随时间扩展“正常”工作情况(和异常工作情况)可以是什么样的参数。例如，逻辑450可以在对应于车辆410在多年期间产生的声音的数据库460中存储音频以建立不同环境(例如位置、气候、道路情况等)和不同工作状态(例如不同速度、悬挂设定等)中的“正常”工作参数的大型库，这可以帮助逻辑450更好表征和确定哪些音频特征在正常参数内以及哪些是异常的。在一些情况中，数据库460在发生新故障机构(或经由众包(crowdsourcing)由云接收)时可以被递归地更新。例如，在部件故障(例如废气支撑件破损)之前发生的未识别的异常音频特征可以与该特定故障相关联以用于将来的诊断。

数据库560可以以软件、固件、硬件或其组合来实施。数据库460可以是音频参考库，用于将来自车辆410上的音频源的音频特征与已知指示正常工作、故障模式或故障模式正在发生的数据库460上存储的声音(音频特征)进行比较。

在一些实施方式中，数据库460可以包含当在正常工作情况下驾驶时车辆410如何发出声音的音频样本(音频特征)。数据库460可以包括在变化表面(道路、高速路、非铺装路面、填过坑的路面、潮湿或被雪覆盖的表面等)、变化的天气情况(冷/温暖/热气候、降水、强风等)等的正常驾驶情况。数据库460可以随时间扩展车辆410的音频库以创建在更多变化的工作情况的改善和扩展的参考内容。

在一些实施方式中，数据库460可以包含当在异常工作情况(即，非典型或异常音频特征)下驾驶时车辆410如何发出声音的音频样样本(音频特征)。数据库460可以包括图1的任意的部件110-150(或未示出的其他部件)的故障机构的音频特征。例如，数据库460可以包括刹车退化的各种状态的音频特征，包括刹车盘磨损、刹车盘生锈、刹车蹄片退化等。数据库460可以包括排气系统退化(例如，孔、安装固件问题等)、发动机退化(例如怠速不规则、皮带/皮带轮退化或错位、悬挂退化)等的各种状态的音频特征。数据库460可以被存储在车辆410上，存储在云(未示出)中，或其组合。在一些实施方式中，数据库460可以通过用于车辆410的特定厂商和型号的众包(crowdsourcing)数据(例如经由云)被增强以用于更鲁棒的参考数据库。在进一步实施方式中，处理和逻辑也可以被推送到云以用于进一步处理，以代替或结合处理器440、逻辑450和数据库460。本领域技术人员可以理解有许多修改、变形和替换。

在非限制性示例中，当麦克风n1-n4检测到产生大声的啸声(screechingsound)(音频特征)的音频源时，逻辑450可以确定其位置(使用音频信号之间的相位差)，并将啸声音频特征与音频数据库460中的声音进行比较。在一些情况中，音频源的位置可以用于过滤全部数量的存储的音频特征。例如，如果音频源的位置被确定在车辆的410的轮窝附近，则参考音频特征可以被局限到与轮子、刹车或该特定位置附近的连接/转向部件相关联的这些参考音频特征。当确定匹配(例如，刹车过度损耗)时，可以向显示器470发送提醒以通知驾驶员该故障机构。

图5示出了根据某些实施方式的使用音频信号、传感器数据和环境数据自动检测车辆故障的系统500的简化框图。系统500可以与系统400类似(即，包括车辆110、麦克风n1-n4等)，只是还加入了gps数据570和交通数据580作为数据库560和传感器数据570的部分。

音频块530可以包括从多个麦克风(例如麦克风n1-n4)接收的音频数据，还可以支持音频电路(例如，a/d转换器、音频过滤器等)，如以上参考图4所述的。

传感器数据570可以包括从麦克风以外的传感器接收的数据，其可以用于帮助系统500确定某些音频特征的原因。例如，传感器数据570可以包括压力传感器数据(例如来自乘客座位)，其指示乘客是否坐在车厢中的相应座位上。知道车辆是负重(例如，驾驶员和乘客体重600磅)还是没有负重(例如驾驶员体重150磅)可以修改可能由悬挂系统导致的期望的音频特征。在这样的情况中，系统500(即逻辑块550)可以将从悬挂系统接收的音频数据(音频特征)与更合适的音频参考(例如重载下的悬挂vs轻载下的悬挂)比较以用于更精确的分析。在另一示例中，驾驶员可以正使用非常高功率的音频系统播放音乐，这可能导致整车振动。这些振动可以被传递到车辆的各种部件(例如，车辆部件110-150)，这会人为在原本不应该会振动或产生声音的车辆部件中引入误报的(falsepositive)异常声音(音频特征)。这样，逻辑550可以使用非音频传感器数据来帮助诊断某些异常音频特征的原因。传感器数据可以包括对应于车辆性能特性、信息娱乐系统特性、车辆设置特性等的数据。

在一些实施方式中，gps数据570可以是数据库560的部分。gps数据570可以有用于帮助逻辑550基于车辆的位置过滤和/或修改音频数据。例如，州际高速路可以比乡村道路包括明显更多的背景噪声(例如，白噪声)。但是，乡村道路上可能有坑孔、岩石以及不平的部分，导致车辆部件(例如悬挂系统、转向控制系统等)相比于在维护很好的高速路有不同的响应。逻辑550可以使用gps数据来将位置信息(例如环境数据)考虑进来以修改异常音频特征与更合适的音频参考(例如匹配位置/环境数据的参考音频特征)的比较以用于更精确的分析。

在一些实施方式中，交通数据580可以是数据库560的部分。交通数据580可以有用于帮助逻辑550基于附近交通情况过滤和/或修改音频数据。繁忙交通会增大白噪声(其可以作为共模信号被抵消)，来自附近汽车的异常声音(音频特征)(如果通过分析音频相位差定位音频源，其可以被过滤掉)，以及可以通知车辆驾驶情况(例如，频繁启动/停车等)，这可以影响车辆部件性能(例如，悬挂系统)。这可以帮助逻辑550选择更合适的数据库参考来与异常音频信号进行比较。

其他传感器和/或环境数据可以用于进一步改善音频数据分析，包括时间、天气情况、车速等，这些可以是本领域技术人员所理解的。

传感器信号与音频信号相关

在一些实施方式中，传感器数据570可以与音频数据相关以帮助诊断某些车辆故障。例如，传感器数据570和音频数据可以基于时间被相关以帮助确定异常音频信号的原因。例如，逻辑550可以确定异常音频信号仅在a/c压缩机开启时或在发动机rpm上升到某阈值以上时才发生。在一些情况中，可以发现更复杂的关系。例如，特定声音(异常音频信号)可以仅在电动车或插电混合动力车中的电池的电荷状态在或低于某值、a/c开启以及信息娱乐系统在特定工作模式中时才发生。机器学习操作可以很好适合这些类型的情形。例如，逻辑550可以随时间确定电池、a/c和信息娱乐系统的每一个在任意给定时间的状态的许多组合中的仅一种倾向导致异常音频信号发生。使用机器学习，逻辑550可以在之前数据日志(例如，在存储设备中、数据库560中，等等)中寻找发生异常音频信号的实例，并事后测试(backtest)在时间段(例如一个月)已确定的状态的组合以验证异常音频信号与电池、a/c和信息娱乐系统的状态组合之间的关系是否是确凿的。应当理解在一些实施方式中，相位分析可以用于确定车辆外的噪声。例如，车辆外发现的共同噪声可以具有可以使用相位分析检测的特征。车辆外发现的噪声可以包括风噪、来自暴风雨、冰雹或其他类型的天气的噪声、来自经过车辆的卡车的噪声、来自火车的噪声和/或来自从车辆外发出的音乐的噪声。

图6是根据某些实施方式的来自车辆上的麦克风(例如m1、n1等)的音频信号与来自方向盘的传感器测量的相关性的曲线600。信号610可以是异常音频特征相对绘图和时间，其可以表示车辆410中的故障模式。信号620可以对应于车辆410上的方向盘的转动。正信号可以对应于方向盘左转，负信号可以对应于右转。信号的幅度可以对应于方向盘的转动量(例如，用度来衡量)。

在时间t1，异常音频信号发生，且方向盘传感器同时报告方向盘向左转动45°。逻辑450可以标记该相关性并将其存储用于将来的参考(例如，在本地存储中，数据库460中，云中等等)。在时间t2，方向盘传感器报告方向盘左转23°且没有同时的异常音频信号。在时间t3，方向盘传感器报告方向盘右转55°，没有同时的异常音频信号。这时，逻辑550可以例如确定转动方向盘与异常信号之间一般来说没有很强的相关性。在时间t4，异常音频信号发生且方向盘传感器同时报告方向盘左转65°。这时，逻辑550可以识别左转超过45°与异常音频信号之间有某种相关性。使用机器学习方面，逻辑550可以使用异常音频信号的重复出现来修改已经确定的相关性并提供更精确的分析。可替换地或另外地，逻辑550可以事后测试(backtest)相关性以了解当方向盘左转45°时在之前的实例中是否发生异常音频信号。例如，逻辑550可以确定异常音频信号在时间上倒回去声音越来越小(即，幅度更小)。在这样的情况中，逻辑550可以进一步推出异常音频信号在特定时间帧开始并可以相互参考其他事件(例如，其他传感器、日历事件、环境数据等)以准确确定具体原因。例如，逻辑550可以确定异常音频信号在对车辆进行保养服务之后开始发生。本领域技术人员根据本公开可以知道使用上述的技术可以在实施方式中实施许多示例、应用、组合、变形、相互参考的分析等。

图7示出了根据某些实施方式的包括使用音频信号自动检测车辆故障的全包含系统和车辆的系统700的简化框图。系统700可以是无所不包的，由此所有的逻辑处理(音频分析、位置检测)和数据库比较由车辆上的部件来执行。在一些实施方式中，通信能力(例如经由蜂窝、wi-fi、zigbee、rf等)可以用于将系统700连接到云或连接到其他车辆以用于众分享/众包(crowdsharing/sourcing)数据库数据(例如，众分享数据(crowdsharingdata)以增强并改善数据库参考数据)。

图8示出了根据某些实施方式的包括通信耦合到云用于使用音频信号自动检测车辆故障的多个车辆的系统800的简化框图。在系统800中，每个车辆810-830可以卸载被配置用于自动检测车辆故障的资源到云840中场外资源。在一些实施方式中，云840可以包含逻辑(如上所述)、数据库以及一个或多个处理器，用于执行上述的分析的一些或所有方面。例如，车辆810可以从麦克风的本地阵列接收音频数据并将该音频数据传递到云以使用相位分析(例如如上参考图2-3所述)确定音频源(音频数据的音频源)的位置。云还可以将该音频数据与存储在云上的数据库进行比较以诊断任意异常音频特性。数据库(如本公开中所述的)可以包括特定车辆提供的音频数据的集合并还可以包括许多车辆众包(crowdsourced)的数据。数据库还可以包括关于音频信号与其他数据(例如，车辆性能数据、环境数据等)之间的相关性等的更复杂的信息，如参考图6所示的。云可以是任意合适尺寸的联网的计算设备，其可以被配置成共享计算资源。本领域技术人员可以理解单独车辆(例如车辆810-830)与云840之间共享资源可以有许多变形和替换。

图9示出了根据某些实施方式的使用音频信号自动检测车辆故障的简化流程图900。方法900可以由处理逻辑来执行，该处理逻辑可以包括硬件(电路、专用逻辑等)、在合适硬件(例如通用计算系统或专用机器)上操作的软件、固件(内嵌软件)或其任意组合。在某些实施方式中，方法900可以由图4的处理器440和逻辑块450、一个或多个处理器或其他合适的计算设备来执行。

在步骤910，方法900可以包括接收位于车辆上(例如，车辆410的内部和/或外部部分)上的至少一个麦克风(例如n1)检测的音频数据。音频数据可以对应于车辆产生的声音，例如以上参考图1描述的各种车辆部件(例如，来自悬挂系统120、转向控制系统130、发动机140等)。

在步骤920，方法900可以包括将音频数据输入到具有训练模型的分析模块。训练模型可以将各种音频数据与对应的车辆故障情况相关联。各种音频数据与对应的车辆故障情况可以被存储在例如数据库460中，并可以由车辆制造商提供(例如，在制造车辆时预先加载)，由其他共享数据库提供(例如经由众分享(crowdsharing)、云等)或通过这些的组合来提供。各种音频数据还可以由车辆随时间产生。例如，当新音频数据到达时，其可以连同各种音频被存储以建立可能故障情况的数据库。

在步骤930，方法900可以包括从分析模块得到基于音频数据的假定车辆故障情况。在一些实施方式中，逻辑450可以通过将音频数据与其各种音频数据和对应车辆故障的数据库进行比较来假定车故障情况。在某些实施方式中，训练模型可以通过机器学习来训练。例如，随着更多的输入数据被得到并作出假定，分析模块可以基于之前的结果(例如验证的诊断)、巩固数据(例如，其他非音频传感器证实假定故障情况)，或来自其他源(例如众分享(crowdsharing)、集中数据库等)的数据修改分析。本领域技术人员可以理解关于机器学习的方面有许多变化、修改和替换。图9的方法步骤的一些或全部可以在车辆中被执行(例如在逻辑450和处理器460中)，或可以在资源间被分配(例如在如图8所示和描述的云中)。

应当理解图9中示出的特定步骤提供根据某些实施方式的使用音频信号自动检测车辆故障的特定方法900。根据替换实施方式也可以执行其他顺序的步骤。例如，可替换实施方式可以以不同顺序执行上述的步骤。此外，图9中示出的单独的步骤可以包括多个子步骤，其可以以对该单独步骤合适的不同顺序被执行。此外，依据特定应用可以添加或移除另外的步骤。例如，传感器数据(来自非音频传感器)可以被输入到分析模块，其可以进一步将传感器数据与各种音频声音以及对应的车辆故障情况相关联。本领域技术人员可以明白并理解图900的许多变形、修改和替换。

图10示出了根据某些实施方式的使用音频信号自动检测车辆故障的简化流程图1000。方法1000可以由处理逻辑执行，其可以包括硬件(电路、专用逻辑等)、在合适硬件上操作的软件(例如通用计算系统或专用机器)、固件(嵌入软件)或其任意组合。在某些实施方式中，方法1000可以由图4的处理器440和逻辑块450、一个或多个处理器或其他合适的计算设备执行。

在步骤1010，方法1000可以包括接收位于车辆(例如车辆410的内部和/或外部部分)的麦克风(例如n1)检测的音频数据。音频数据可以对应于车辆产生的声音，例如以上参考图1描述的各种车辆部件(例如，来自悬挂系统120、转向控制系统130、发动机140等)。

在步骤1020，方法1000可以包括将音频数据与存储在音频数据库上的参考音频数据进行比较。参考音频数据可以包括在正常工作情况下车辆产生的声音。音频数据库可以被存储在车辆上的本地存储器中，存储在远端(例如云、在车队中的其他车辆中，等等)或这两者的组合。

在步骤1030，方法1000可以包括识别音频数据中与正常工作情况下车辆产生的声音不同的异常音频特征。可替换或另外地，音频数据库可以包括在一个或多个故障情况中工作的车辆产生的声音，以及方法1000还可以包括将音频数据中的异常音频特征与数据库中的在一个或多个故障情况下工作的车辆产生的声音进行比较，以及识别异常音频特征与在一个或多个故障情况下工作的车辆产生的一个或多个声音的匹配。

应当注意到车辆产生的声音可以包括随时间从特定车辆收集的检测并保存的声音(例如使用机器学习)，对应于车辆的特定厂家和型号的声音(例如由车辆制造商、众包(crowdsourcing)等提供)或其组合。

在一些实施中，音频数据(包括异常音频特征)还可以从设置在车辆外部部分的一个或多个另外的麦克风接收。在步骤1040，方法1000可以包括确定从麦克风接收的音频数据和一个或多个另外的麦克风的每一个接收的音频数据之间的相位差。如上所述，麦克风位于车辆上的不同位置。车辆产生的声音(例如，异常音频特征)会被每个麦克风在不同时间检测到，因为它们各自的位置关于声源在不同的位置。这些不同的位置在每个麦克风检测的音频数据中代表相位差，也称为定时差。

在步骤1050，方法1000可以包括基于对应于麦克风与一个或多个另外的麦克风的每一个接收的异常音频特征的音频数据的计算的相位差来计算异常音频特征的源的位置。

在步骤1060，方法1000可以包括基于以下的至少一者来确定异常音频特征的原因：异常音频特征的对应的音频特性，异常音频特征与在一个或多个故障情况下工作的车辆产生的一个或多个声音的匹配，以及异常音频特征的源的计算出的位置。

应当理解图10示出的特定步骤提供根据某些实施方式的使用音频信号自动检测车辆故障的特定方法1000。根据替换实施方式也可以执行其他顺序的步骤。例如，替换实施方式可以以不同的顺序执行上述的步骤。此外，图10中示出的单独步骤可以包括多个子步骤，其可以以对该单独步骤合适的不同顺序被执行。此外，依据特定应用可以添加或移除另外的步骤。本领域技术人员可以明白并理解方法1000的许多变形、修改和替换。

图11是根据某些实施方式的用于执行使用音频信号自动检测车辆故障的某些方面的计算机系统1100的简化框图。计算机系统1100可以用于实施参考图4至9描述的任意计算机系统/设备(例如逻辑450、数据库460、处理器440)。如图11所示，计算机系统1100可以包括一个或多个处理器1104，用于经由总线子系统1102与多个外围设备通信。这些外围设备可以包括存储设备1106(包括长期存储和工作存储器)、用户输入设备1108(例如麦克风n1-n4)、用户输出设备1110(例如，视频显示器，用于基于方法900向车辆传递问题)以及通信子系统1112。

在一些示例中，内部总线子系统1102可以提供用于使得各种部件和计算机系统1100的子系统在需要时彼此通信的机制。虽然内部总线子系统1102示意性示出为单个总线，但是总线子系统的可替换实施方式可以使用多个总线。此外，通信子系统1112可以用作用于在计算机系统1100与其他计算机系统或网络(例如在云中)之间通信数据的接口。通信子系统1112的实施方式可以包括有线接口(例如以太网、can、rs232、rs485等)或无线接口(例如zigbee、wi-fi、蜂窝等)。

在一些情况中，用户接口输入设备1108可以包括麦克风、键盘、定点设备(例如鼠标、轨迹球、触摸板等)、条形码扫描仪、集成到显示器的触屏、音频输入设备(例如语音识别系统等)、人机界面(hmi)和其他类型的输入设备。一般来说，使用术语“输入设备”旨在包括所有可能类型的用于将信息输入到计算机系统1100的设备和机制。此外，用户接口输出设备1110可以包括显示器子系统或不可视显示器例如音频输出设备等。显示器子系统可以是任意已知类型的显式设备。一般来说，使用术语“输出设备”旨在包括用于从计算机系统1100输出信息的所有可能类型的设备和机制。

存储设备1106可以包括存储器子系统和文件/盘存储子系统(未示出)，其可以是非暂态计算机可读存储介质，其可以存储提供本公开的实施方式的功能(例如方法900)的程序代码和/或数据。在一些实施方式中，存储设备1106可以包括多个存储器，包括主随机存取存储器(ram)用于在程序执行期间存储指令和数据，以及只读存储器(rom)，其中可以存储固定指令。存储设备1106可以提供用于程序和数据文件的持续(即非易失性)存储，并可以包括磁或固态硬盘驱动、光驱以及相关联的可移除介质(例如，cd-rom、dvd、蓝牙等)、可移除闪存驱动或卡和/或本领域中已知的其他类型的存储介质。

计算机系统1100可能还包括通信子系统1112，其可以包括但不限于调制解调器、网卡(无线或有线)、红外通信设备、无线通信设备和/或芯片集(例如蓝牙设备、802.11设备、wifi设备、wimax设备、蜂窝通信设施等)等等。通信子系统1112可以允许数据与网络、其他计算机系统和/或这里描述的任意其他设备进行交换。在许多实施中，计算机系统1100还可以包括非暂态工作存储器，其可以包括上述的ram或rom设备。

应当理解计算机系统1100是示例性的且不旨在限制本公开的实施方式。具有比系统1100更多或更少的部件的许多其他配置是可能的。

多数实施方式使用本领域技术人员熟悉的至少一个网络用于使用多种商业可得的协议的任意支持通信，协议例如是tcp/ip、udp、osi、ftp、upnp、nfs、cifs等。网络可以是例如局域网、广域网、虚拟个人网、因特网、内部网、外部网、公共交换电话网、红外网、无线网以及其任意组合。

非暂态存储介质和计算机可读存储介质用于包含代码或代码的部分，其可以包括在本领域中已知或使用的任意合适的介质，但不限于以用于信息存储的任意方法或技术实施的易失性和非易失性、可移除和不可移除介质，例如是计算机可读指令、数据结构、程序模块或其他数据，包括ram、rom、电可擦除可编程只读存储器(eeprom)、闪存或其他存储技术，cd-rom、dvd或其他光存储、磁盒、磁带、磁盘存储或其他磁性存储设备或任意其他可以用于存储期望的信息并可以被系统设备访问的介质。基于这里提供的公开和教示，本领域技术人员可以理解其他方式和/或方法实施各种实施方式。但是，计算机可读存储介质不包括暂态介质，例如载波等。

在描述公开的实施方式的上下文中(尤其在权利要求书的上下文中)使用术语“一”和“该”以及类似的指示词被理解为包括单数和复数，除非另有指明或上下文明显是相反意思。术语“包括(comprising)”、“具有(having)”、“包含(including)”以及“含有(containing)”被理解为开放式术语(即，意思是“包括但不限于”)，除非另有指明。术语“连接”被理解为部分或全部被包含在、附着到或连接一起，即使存在中间物。短语“基于”应当被理解为开放式的，且不以任何方式限制，且在合适的情况下旨在被解释或其他方式理解为“至少部分基于”。这里值范围的记载仅旨在用作速记方法来单独指落入范围内的每个单独的值，除非另有指明，且每个单独的值被结合在说明书中如同在本文中单独记载。这里描述的所有方法可以以任意合适的次序被执行，除非另有指明或上下文明确有相反意思。使用这里提供的任意和所有示例或示意性语言(例如“例如”)仅旨在更好阐明本公开的实施方式且不对本公开的范围进行限制，除非另有要求。说明书中没有语言应当被理解为指示对本公开的实施是必要的任意未要求的元素。