本公开大体涉及诊断工具，诸如扫描工具。更具体地，本公开涉及能够使用机载监测失火数据和物理寻址的诊断工具。
背景技术：
诊断故障代码通常由机动车辆制造商用来指示与组件（诸如机动车辆的引擎）有关的问题。然而，某些制造商，诸如ford，将其用于失火的参数（最小值/最大值）设定为过于宽的值，使得从未设定用于潜在或实际失火的dtc。因而，引起难以恰当地诊断失火是引擎“发出噼啪声”或缺失电力的原因。甚至当“失火”类型数据可用于使用can前的年份（即，fordscp引擎系统）中的服务0x22（通过公共id的请求）的ford增强数据时，“失火数据”仍将难以就哪个气缸在失火进行解译。从fordcan（控域网）引擎系统开始，从使用公共id的增强服务消除“失火”数据。因此，“失火”数据在ford的增强数据中用于ford的can系统类型引擎数据流中不可获得，这然后挫败技术人员。
甚至当技术人员可以使用诊断工具来获取气缸的“失火”数据时，“失火”数据（如果可获得的话）仅是在那个时刻气缸点火数据的快照，并且因此，确定哪个或哪些气缸在失火再次是困难的。例如，当仅向技术人员示出一次气缸点火的“快照”时，主要发生在传输从第二齿轮去往第三齿轮之间的失火将难以检测。这是因为失火是间歇的并且因而快照必须处于正确时间。
为了缓和这些挫败，存在能够检索增强can引擎系统上（诸如ford上）的“失火”数据并且将它显示给技术人员以便恰当地诊断机动车辆的需要。
技术实现要素：
通过本公开在很大程度上满足前述需要，其中在一个方面中，在一些实施例中提供了一种装置以便包括诊断工具，所述诊断工具能够在利用can协议的机动车辆中显示实况模式6数据。
在一个实施例中，提供了一种机动车辆诊断工具，并且所述机动车辆诊断工具可以包括：诊断处理器，配置为执行计算指令；连接器接口，配置为与机动车辆中的连接器连接并利用处理器从机动车辆检索机动车辆诊断数据，其中机动车辆诊断数据是模式6气缸失火数据；与处理器通信的显示器，配置为显示机动车辆诊断数据；无线通信接口，与处理器通信并配置为与具有机动车辆诊断数据库的远程设备通信；以及存储器，与处理器通信，所述存储器包含计算指令，所述计算指令在由处理器执行时使处理器：检索包括诊断故障代码（dtc）和模式6气缸失火数据的机动车辆诊断数据，通过使用机动车辆中的引擎控制器的物理寻址来连续地且动态地检索模式6气缸失火数据；在显示器上生成对应于机动车辆的每一个所支持的气缸的单独气缸失火数据的多个可选择图标；如果有的话，在可选择图标上指示针对每一个所支持的气缸的数个气缸失火；以及激活远程设备上的网络浏览器以便开始维修过程。
在另一个实施例中，一种非暂时性机器可读存储介质包括机器可读指令以用于使诊断工具的处理器执行以下方法：检索包括诊断故障代码（dtc）和模式6气缸失火数据的机动车辆诊断数据，通过使用机动车辆中的引擎控制器的物理寻址来连续地且动态地检索模式6气缸失火数据；在诊断工具的显示器上生成对应于机动车辆的每一个所支持的气缸的单独气缸失火数据的多个可选择图标；如果有的话，在可选择图标上指示针对每一个所支持的气缸的数个气缸失火；以及激活远程设备上的网络浏览器以便开始维修过程。
在又一个实施例中，提供了一种机动车辆诊断工具，并且所述机动车辆诊断工具包括：用于处理的部件，配置为执行计算指令；用于对接的部件，配置为与机动车辆中的连接器连接并利用用于处理的部件从机动车辆检索机动车辆诊断数据，其中机动车辆诊断数据是模式6气缸失火数据；与用于处理的部件通信的用于显示的部件，配置为显示机动车辆诊断数据；用于无线通信的部件，与用于处理的部件通信并配置为与具有机动车辆诊断数据库的远程设备通信；以及用于存储的部件，与用于处理的部件通信，存储器包含指令，所述指令在由用于处理的部件执行时使用于处理的部件：检索包括诊断故障代码（dtc）和模式6气缸失火数据的机动车辆诊断数据，通过使用机动车辆中的引擎控制器的物理寻址来连续地且动态地检索模式6气缸失火数据；在用于显示的部件上生成对应于机动车辆的每一个所支持的气缸的单独气缸失火数据的多个可选择图标；如果有的话，在可选择图标上指示针对每一个所支持的气缸的数个气缸失火；以及激活远程设备上的网络浏览器以便开始维修过程。
因而已经相当宽泛地概述了本公开的某些实施例以便可以更好地理解其在本文中的详细描述，并且以便可以更好地领会对现有技术的当前贡献。当然存在以下将描述并且将形成随附于此的权利要求书的主题的本公开的附加实施例。
在这一方面中，在详细地解释本公开的至少一个实施例之前，要理解到，本公开在其应用上不限于构造的细节以及不限于在以下描述中阐述或者在附图中图示的组件的布置。本公开能够具有除那些描述的之外的实施例并且能够以各种方式实践和实施。而且，要理解到，本文采用的短语和术语以及摘要是用于描述的目的并且不应当视为限制。
照此，本领域技术人员将领会到，本公开所基于的概念可以容易地被用作用于实施本公开的若干目的的其它结构、方法和系统的设计的基础。因此重要的是，在它们没有偏离本公开的精神和范围的限度内，权利要求要视为包括这样的等同构造。
附图说明
图1描绘了根据本公开的示例性实施例的诊断工具的正视图。
图2是根据本公开的实施例的图1的诊断工具的组件的框图。
图3图示了根据本公开的实施例的示例性图形用户接口（gui）。
图4图示了根据本公开的另一个实施例的另一个示例性gui。
图5图示了根据本公开的实施例的显示失火数据的方法。
具体实施方式
现在将参照附图中的绘图来描述本公开，其中相同附图标记自始至终是指相同部分。依照本公开的实施例提供了一种计算设备，诸如诊断工具、笔记本电脑、平板电脑或智能电话，其可以针对“失火”数据而询问具有can引擎系统的机动车辆并且然后在诊断工具上显示它。
图1图示了根据本公开的实施例的诊断工具100的正视图。诊断工具的示例是来自boschautomotiveservicesolutions公司（owatonna，mn）的genisys®touch或encore。诊断工具100可以包括外壳102、显示器104、功能按钮或用户接口106、电力按钮108、具有手指（拇指）接收部分112的持握部分110、相机114以及图形用户接口120（在下文讨论）。电力按钮108还可以用于将诊断工具100置于待机状态以便在不使用时节省电池电力。
持握部分110可以由包括水凝胶的聚合物制成以容易持握。手指接收部分112可以配置为接收手指，诸如用户的拇指，以便辅助于诊断工具100的更好持握。功能按钮或用户接口106可以配置用于用户期望的任何功能，包括录入、后退、前进、向左、向右、向上、向下、传输、接收、返回、重新开始等。功能按钮还可以包括功能的任何组合中的多个功能，诸如录入并且然后后退等。用户接口106还可以包括具有数字和字母和/或字母数字等的键盘。
显示器104可以是任何类型的显示器，包括触摸屏显示器、lcd、led、vga、oled、svga以及其它类型的显示器。显示器104可以是彩色的、非彩色的（例如，灰阶的）或二者的组合。显示器104可以显示信息，诸如诊断工具100可以诊断的机动车辆的制造、型号、年份，诊断工具可以运行的各种诊断测试，诊断工具已经接收的诊断数据，机动车辆中的各种组件的基线数据，零件图像，零件信息，以及来自远程服务器的信息（互联网、数据库信息等）。附加地，显示器可以示出视频以供用户查看，并且可以经由内置扬声器（未示出）倾听伴随的音频。扬声器可以是用于立体声音的多个扬声器或单个扬声器。可以包括麦克风（未示出）并且麦克风允许技术人员记录信息，诸如由机动车辆发出的噪声，以用于随后分析或者用于与所存储的数据进行比较。另外，技术人员还可以在测试期间记录评论或注释以用于随后检索和分析。
在一个实施例中，显示器允许用户通过触摸屏输入选择以用于交互式导航和选择，其中技术人员可以通过触碰图形用户接口（gui）120上的选择来选择菜单项目或图标（在下文进一步讨论）。附加地，当被敲击或触碰时，显示器104还可以用于唤醒诊断工具100，如果它处于休眠模式的话。
相机114可以定位为面向用户使得用户可以与远程位置处的另一人员进行视频聊天。相机还可以定位在诊断工具100的任何表面上，包括显示器104的相反侧面上，使得可以拍摄用户期望的任何组件或引擎的零件的图像。
图2是根据本公开的实施例的图1的诊断工具100的组件的框图。在图2中，根据本公开的实施例的诊断工具100可以包括相机114、处理器202、现场可编程门阵列（fpga）214、第一系统总线224、显示器104、复杂可编程逻辑器件（cpld）206、输入设备106或功能按钮、存储器208、内部非易失性存储器（nvm）218（是具有带有软件程序和机动车辆诊断信息（诸如机动车辆诊断软件）的数据库212的特殊诊断存储器）、读卡器220、第二系统总线222、连接器接口211、可选择信号转译器210、gps天线232、gps接收器234、可选的高度计236和无线通信电路238。
在一个实施例中，无线通信电路238可以配置为与耦合到机动车辆的接口（未示出）或另一个远程设备的机动车辆通信接口无线通信。机动车辆通信接口向无线通信电路238发送从机动车辆中的各种电子控制单元（ecu）或引擎系统接收的机动车辆数据和信号。无线通信电路238经由第二系统总线222与处理器202通信。无线通信电路238可以配置为经由rf（射频）、卫星、蜂窝电话（模拟或数字）、bluetooth®、wi-fi、红外、zigbee、局域网（lan）、wlan（无线局域网）、nfc（近场通信）、其它无线通信配置和标准、或其组合进行通信。无线通信电路238允许诊断工具100与其它设备无线通信，诸如与具有远程数据库的远程计算设备（未示出）无线通信。无线通信电路238包括置于其中并且容纳在外壳102内或者可以在外部位于外壳102上的天线或收发器（未示出）。
信号转译器210将通过无线通信电路238或通过连接器接口211从ecu单元接收的信号调控为与诊断工具100兼容的经调控的信号。信号转译器210可以例如利用以下通信协议进行通信：j1850（vpm和pwm）、iso9141-2信号、通信冲突检测（ccd）（例如，克莱斯勒冲突检测）、数据通信链路（dcl）、串行通信接口（sci）、控域网（can）、关键字2000（iso14230-4）、obdii或者在机动车辆中实现的其它通信协议。
用于以特定通信协议转译和发送的电路可以由fpga214（例如，由三态未使用收发器）选择。信号转译器210还可以经由第一系统总线224耦合到fpga214和读卡器220。fpga214通过信号转译器210和无线通信电路238向ecu单元传输以及从ecu单元接收信号（即，消息）。
fpga214可以通过第二系统总线222而借由各种地址、数据和控制线路耦合到处理器202。fpga214还通过第一系统总线224耦合到读卡器220。处理器202还可以耦合到显示器104以便向用户输出期望信息。处理器202通过第二系统总线202与cpld206通信。附加地，处理器202可以编程为经由cpld206或经由触摸屏显示器104而借由输入设备106从用户接收输入。cpld206可以提供用于解码来自诊断工具100的用户的各种输入的逻辑并且还提供用于各种其它对接任务的胶连逻辑。
处理器202是配置为从机动车辆的ecu检索诊断信息的特殊处理器或诊断处理器。处理器可以适配为从机动车辆的obdii检索和处理模式6信息以便检索“失火”数据并且以图形格式为用户显示它。
存储器208和内部非易失性存储器218可以耦合到第二系统总线222，这允许与处理器202和fpga214的通信。存储器208可以包括应用相关数量的动态随机存取存储器（dram）、硬驱动和/或只读存储器（rom）。运行诊断工具100的软件（包括gui）可以存储在包括任何其它数据库的存储器208或218中。诊断软件包括指令使得处理器202可以从机动车辆的obdii连续地且动态地检索模式6数据并且在诊断工具的显示器上以图形格式（诸如gui）显示它。数据库212可以包括诊断信息以及涉及机动车辆的其它信息。
内部非易失性存储器218可以是电气可擦除可编程只读存储器（eeprom）、闪速rom或其它类似的存储器。内部非易失性存储器218可以提供例如用于启动代码的存储、自诊断、各种驱动器以及用于fpga图像的空间（如果期望的话）。附加地，内部非易失性存储器218还可以包括软件，诸如用于在触摸屏显示器104上渲染和显示图形（例如，图标或模块）的图形模块。如果在fpga214中实现少于全部的模块，存储器218可以包含可下载图像使得fpga214可以重新配置用于通信协议的不同群组。
可以包括gps天线232和gps接收器234并且它们可以安装在外壳102中或上或其任何组合。gps天线232电子耦合到gps接收器234并且允许gps接收器与绕地球轨道运行的各种卫星通信（检测和解码信号）。在一个实施例中，gps天线232和gps接收器234是一个设备而不是两个设备。gps接收器234和gps天线232可以电子地耦合到处理器202，处理器202可以耦合到存储器208、218或读卡器220中的存储卡。存储器可以用于存储制图数据，诸如电子地图。诊断工具可以包括美国（或使用的国家）、北美洲的所有地图，或者可以具有诊断工具所位于的地区或州。在可替换实施例中，诊断工具可以具有世界或者用户期望的世界的任何部分的所有地图。这允许诊断工具成为gps设备，使得驾驶员可以从一个位置驾驶到另一个位置。地图可以叠覆或者可以并入其它gps设备（智能电话）的交通、本地事件和位置，以及对于技术人员可以有用的其它信息。通过能够利用gps定位其它诊断工具，那么技术人员可以能够使用诊断工具来定位彼此以便进行会面或者从事社交事件。
gps接收器与某一数目的卫星通信并且“锁定”至某一数目的卫星以便具有其全球位置上的“方位”。一旦位置固定，gps接收器就在处理器的帮助下可以确定精确位置，包括经度、纬度、海拔、移动速度以及诊断工具100的其它导航数据。
假设gps接收器不能够锁定到最小数目的卫星以便确定海拔或者出于任何原因而不能够确定海拔，高度计236可以用于确定诊断工具100的海拔。高度计236电子耦合到处理器202并且可以提供诊断工具100的海拔或高度。高度计236可以耦合到气压传感器（未示出）以便校准由高度计确定的高度测量结果。传感器可以定位在诊断工具100的外壳102的内部或外部。轻微的大气压力改变可能影响高度计236的精度，因而，诊断工具可以通过连同现有技术中已知的校正因子与高度计236结合地使用传感器来校正这些改变。
在可替换实施例中，被测试机动车辆的机动车辆通信接口230经由外部线缆（未示出）而通过连接器接口211与诊断工具100通信。可选择的信号转译器通过连接器接口211与机动车辆通信接口230通信。
图3图示了根据本公开的实施例的示例性图形用户接口（gui）300。gui300可以包括各种图标、信息横幅、模块、接口元件等。图标或模块可以通过利用手指或触笔等在显示器104上触碰或者通过用户接口106来激活。显示器104可以是触敏的并且能够解译手指接触、手指敲击手势、手指挥击手势、触笔移动、其任何组合等。应当理解到，在一些实施例中，利用来自另一个输入设备的输入（例如，基于鼠标的输入或触笔输入）来替换手指输入中的一个或多个。例如，可以利用鼠标点击（例如，替代于接触）紧随有光标沿挥击路径的移动（例如，替代于接触的移动）来替换挥击手势。另外的实施例，可以利用鼠标点击而同时光标位于敲击手势的位置之上（例如，取代于检测接触紧随有中止检测接触）来替换敲击手势。类似地，当同时地检测到多个用户输入时，应当理解到，可以同时地使用多个计算机鼠标，或者可以同时地使用鼠标和手指接触。
gui300包括标题横幅302、机动车辆信息横幅304以及图标或模块306和查看面板308。在该示例中，标题横幅302显示gui300的标题或主题。在该情况下，标题横幅302是用于来自机动车辆的失火数据（模式6）的“数据流”。在该情况下，机动车辆信息横幅304将机动车辆标识为2008fordfocusse2.0，其具有基本型号中的四个气缸。然而，面板308显示用于12气缸机动车辆的默认失火数据，因为消费者机动车辆最多包括12个气缸。
如在面板308中所示，关于每一个气缸的信息可以包含行程滚动平均失火或者当前行程失火。尽管这些是用于失火的计数类型的示例，但是可以利用其它类别的失火，诸如最后行程、三个行程、五个行程、十个行程等中的失火。在当前行程失火的类别之下，这意指在当前行程期间通过特定气缸（例如，气缸编号三）的失火的数目。在行程滚动平均的类别之下，这意指在事件之后通过特定气缸的失火的数目。事件可以是包括相关失火dtc（诊断故障代码）被重置的最后时间、特定气缸具有失火的最后时间、或者诸如维修气缸时的特定日期等的任何事件。滚动平均还可以是基于某个数目的失火，诸如三个、五个、七个等。
在一个实施例中，一旦滚动平均命中由用户设定的失火数目（诸如在事件之后的三个失火），那么通过处理器202，诊断工具可以经由电子邮件、文本消息、电话或者扫描工具的显示器上的消息来提醒用户。可替换地，在另一个实施例中，一旦失火的滚动平均已经命中由用户设定的预确定数目，那么无线通信接口可以启动诊断工具的显示器上或者诸如机动车辆的所有者或维修设施的远程计算设备上的网络浏览器，使得可以安排机动车辆进行维修。维修设施可以是机动车辆当前所处于的设施或者由机动车辆所有者选取的另一个设施。
图4图示了根据本发明的另一个实施例的示例性gui400。gui400可以通过遵循在图5中示出的流程图来获得，如在下文所述。gui400可以包括各种图标、信息横幅、模块、接口元件等。在一个实施例中，gui400包括标题横幅402，其是gui400的主题的标题。在该情况下，标题横幅402包括“数据流”和“失火数据（模式6）”。机动车辆信息横幅404示出了与图3中的机动车辆信息横幅304中的相同机动车辆。附加地，gui400包括图标或模块408-424以及查看面板430。
在gui400中还示出了控制数据记录线路407的数据记录按钮406。一旦例如经由按压而激活，数据记录按钮就将开始针对失火而记录用于被测试机动车辆中的各种气缸的数据。所记录的数据可以包括经由模式6的气缸失火、其它机动车辆诊断数据（诸如引擎rpm、空气流量）、来自节气门位置传感器或o2传感器的数据，以用于比较。
模块408-424图示了涉及数据流的信息，诸如气缸失火和rpm。特别地，模块408图示了气缸1的信息，包括当前行程失火和计数数目（零计数）。该计数意指失火已经基于针对该相关模块的准则而发生的次数。模块410图示了气缸3的信息，包括当前行程失火和计数数目（零计数）。模块412图示了气缸1的信息，包括当前10行程滚动平均失火，并且计数数目为三。在该情况下，10行程滚动平均失火意指模块在对最近10个行程期间已经发生的平均失火数目进行计数，其是三次（而模块408示出在当前行程期间没有发生失火）。模块414图示了气缸3的信息，包括当前10行程滚动平均失火和计数数目（零计数）。
模块416图示了作为流式传送的数据的引擎rpm。该信息可以连同其它模块408-424用于诊断机动车辆，诸如通过比较模块的数据。也就是说，技术人员可以确认与失火有关的问题，因为引擎rpm没有读作处于当所有气缸恰当地点火时用于被测试机动车辆的预限定的“正常”参数内。换言之，当一个或多个气缸如由其它模块所指示正失火时，引擎rpm低于预期为“正常”的情况。模块418图示了气缸2的信息，包括当前行程失火和计数数目（零计数）。类似地，模块420图示了气缸4的信息，包括当前行程失火和计数数目（零计数）。模块422图示了气缸2的信息，包括当前10行程滚动平均失火和计数数目（零计数）。模块424图示了气缸3的信息，包括当前10行程滚动平均失火和计数数目（零计数）。应当指出的是，涉及气缸失火的模块（不是416）已经在gui400中从gui300中示出的那些减少以便仅示出与2008fordfocusse2.0相关联数目的气缸（即，4个气缸）。然而，在其它实施例中，可以示出任何数目的气缸，范围例如从1到12个气缸或更多。
图5图示了根据本发明的实施例的显示失火数据500的方法。在步骤502处，计算设备，诸如具有显示器的诊断工具，可以显示“数据流”群组菜单以供由用户选择。如例如在gui300中所示。在步骤504处，诊断工具从gui300的“数据流”群组菜单接收数据流群组“失火数据（模式6）”306的选择。选择可以通过用户在触摸屏上使用其手指或者触笔等来完成。在步骤506处，诊断工具使用物理寻址ox7e0利用obd监测仪id0xa0请求模式6可用性数据。也就是说，这种询问使用物理寻址ox7e0以便允许诊断工具仅从机动车辆中的引擎（动力传动系）控制器而不是在模式6询问之下可获得的其它控制器来接收诊断信息。在一个实施例中，传输缓冲器将包括ox70、0xe0、ox06、oxa0。一般地，a0是可以支持的obd监测仪id。例如，如果机动车辆具有12个气缸，那么a2是用于“失火气缸1数据”，a3是用于“失火气缸2数据”，a4是用于“失火气缸3数据”，a5是用于“失火气缸4数据”，a6是用于“失火气缸5数据”，a7是用于“失火气缸6数据”，a8是用于“失火气缸7数据”，a9是用于“失火气缸8数据”，aa是用于“失火气缸9数据”，ab是用于“失火气缸10数据”，ac是用于“失火气缸11数据”，并且ad是用于“失火气缸12数据”。在步骤508处，被测试引擎控制器返回原始数据（诸如位）
在步骤518处，诊断工具确定是否支持至少一个气缸，如由步骤512的过程所确定。如果否520，那么过程进行到516并且然后回到502。如果是522，那么在步骤524处，使用用于引擎控制器的物理寻址而利用obd监测仪id来请求模式6数据。在步骤526处，诊断工具转换原始模式6失火数据以用于在诊断工具的显示器上显示。在步骤528处，诊断工具类似于在gui400和模块408-424中示出的那样显示模式6失火数据。在步骤530处，诊断工具确定用户是否想要退出（例如通过命中后退按钮或者出口按钮）数据项目群组“失火数据（模式6）
如本文中示出，提供了一种过程，其通过使用专有增强询问而允许在不再支持实况数据的形式的机动车辆（诸如具有can的ford）中使用。通过使用用于特定引擎控制器的物理地址，可以向诊断工具供应来自该控制器的信息。另外，因为物理地址用于技术人员想要的ecu，那么来自其它ecu的信息没有在提供不想要的信息并且因而相关信息要比常规方法显示得更快。另外，本文公开的方法允许更加准确的诊断，因为不断地示出和记录模式6失火数据的连续和动态更新而不是常规快照。另外，利用本公开的实施例，不再要求依赖设定的dtc来检测失火。
还应当指出，软件实现，诸如如在本文中描述的本公开的gui，可以存储在有形、非暂时性存储介质上，诸如：磁性介质，诸如盘或带；磁光或光学介质，诸如压缩盘或数字视频盘；或者固态介质，诸如存储卡或者容纳一个或多个只读（非易失性）存储器、随机存取存储器或其它可再写（易失性）存储器的其它封装。相应地，本公开被视为包括有形存储介质或分布介质，如本文中所列出并且包括现有技术认识到的在其中存储包括代码段的软件实现的等同物和后继介质。附加地，尽管本文描述了诊断工具，但是本公开可以实现在任何计算设备（具有处理器和存储器）上，诸如个人计算机、笔记本电脑、智能电话、平板电脑等。
本公开的许多特征和优点从详细说明书显而易见，并且因而，意图由随附权利要求书涵盖落在本公开的真实精神和范围内的本公开的所有这样的特征和优点。另外，由于众多修改和变型将是本领域技术人员容易地想到的，因此并不期望将本公开限制于所图示和描述的确切构造和操作，并且相应地，可以诉诸于落入本公开的范围内的所有适合的修改和等同物。