失效诊断信息产生设备和失效诊断信息产生系统的制作方法

专利名称：失效诊断信息产生设备和失效诊断信息产生系统的制作方法
技术领域：
本发明涉及失效诊断信息产生设备、失效诊断信息产生系统等，它们产生车辆失 效诊断中所用的指令信息。
背景技术：
例如，日本专利No. 3799795描述了一种车辆诊断系统，其中，以通过车辆自身诊 断而发现的故障为基础的失效诊断信息被以无线方式传送到外部基站，然后外部基站通过 邮件(邮寄)来提供信息，该信息提示用户对车辆进行修理。在上述车辆诊断系统中，为了 使外部基站能够获取已经执行了修理这样的信息，在从车辆向基站以无线方式传送了以通 过车辆自身诊断而发现的故障为基础的失效诊断信息之后，如果检测到与该失效诊断信息 对应的车辆故障已被消除(受到修理)，则从车辆向基站传送故障已消除信息，该信息表明 消除了故障。另外，并非仅是在车辆自身诊断或在外部诊断中；当车辆的失效受到诊断时，必需 对发生该失效时的车辆信息(例如，发动机负载的变化样式等等)进行诊断。此时，如果把 已经从大量车辆获取的、失效时的各条过往车辆信息与失效的原因相关联以制成数据库， 则此后当在失效时获取了类似的车辆信息时，就从该数据库取回与所获取的车辆信息相对 应的失效原因信息，从而使得可以容易地识别当前的失效原因(并另外识别对该失效进行 修理的方法)。但是，由于复杂的车辆系统等，如果发生车辆故障，则车辆故障的原因中的一些 (根源原因)不能被准确地识别。即使在经销商等处实施车辆的修理或部件更换、并因而曾 经消除了故障时，该故障也可能在此后再现(recur)。在此情况下，修理时识别的失效原因 最终是错误的。如果上述错误识别的信息累积在上述数据库中，则失效诊断的准确性可能恶化。

发明内容
本发明提供了失效诊断信息产生设备、失效诊断信息产生系统等，它们能够通过 对车辆的修理或部件更换之后故障是否再现进行判定，来制成仅有各条可靠信息的数据库。本发明的第一方面提供了一种失效诊断信息产生设备。这种失效诊断信息产生设 备包括修理信息获取装置，用于获取修理信息，所述修理信息表明伴随车辆的故障而实施 的修理或部件更换的内容，或表明所述故障的原因；故障时车辆信息获取装置，用于获取故 障时车辆信息，所述故障时车辆信息表明发生所述故障时所检测到的车辆状态；指令信息 产生装置，用于根据所述修理信息和所述故障时车辆信息而产生指令信息，所述指令信息 可用于未来的修理或部件更换；再现信息获取装置，用于获取再现信息，所述再现信息表明 在所述车辆的修理或部件更换之后，所述故障是否已经再现。当根据所述再现信息而判定 为在所述车辆的修理或部件更换之后所述故障尚未再现时，所述指令信息产生装置执行下述(1)和(2)中的任意一者。即，(1)指令信息产生装置根据与尚未再现的所述故障有关 的修理信息和故障时车辆信息而产生指令信息，或者(2)判定将由所述指令信息产生装置 根据与尚未再现的所述故障有关的修理信息和故障时车辆信息而产生的指令信息用于未 来的修理或部件更换。在这个第一方面，在判定为到从所述车辆的修理或部件更换开始经过了预定时间 长度时为止或者到所述车辆行驶了预定距离时为止所述故障尚未再现时，所述指令信息产 生装置可以根据与尚未再现的所述故障有关的修理信息和故障时车辆信息而产生指令信 息，或者可以判定将由所述指令信息产生装置根据与尚未再现的所述故障有关的修理信息 和故障时车辆信息而产生的指令信息用于未来的修理或部件更换。在这个第一方面，在判定为到从所述车辆的修理或部件更换开始经过了预定时间 长度时为止或者到所述车辆行驶了预定距离时为止所述故障已经再现时，所述指令信息产 生装置可以不根据与尚未再现的故障有关的修理信息和故障时车辆信息而产生指令信息， 或者可以判定不将由所述指令信息产生装置根据与尚未再现的故障有关的修理信息和故 障时车辆信息而产生的指令信息用于未来的修理或部件更换。在上述第一方面，可以仅在判定为到从所述车辆的修理或部件更换开始经过了预 定时间长度时为止或者到所述车辆行驶了预定距离时为止所述故障尚未再现时，所述修理 信息获取装置才获取与尚未再现的所述故障有关的修理信息，并且所述故障时车辆信息获 取装置才获取所述故障时车辆信息，所述指令信息产生装置可以根据所获取的修理信息和 故障时车辆信息而产生指令信息。在这个第一方面，在判定为到从所述车辆的修理或部件更换开始经过了预定时间 长度时为止或者到所述车辆行驶了预定距离时为止所述故障已经再现时，所述指令信息产 生装置可以丢弃与已经再现的故障有关的修理信息和故障时车辆信息，并且在已经产生了 与已经再现的故障有关的指令信息时可以丢弃与已经再现的故障有关的指令信息。在这个第一方面，可以仅在判定为到从所述车辆的修理或部件更换开始经过了预 定时间长度时为止或者到所述车辆行驶了预定距离时为止所述故障尚未再现时，所述指令 信息产生装置才将与尚未再现的故障有关的指令信息提供给车辆修理支持设备，所述车辆 修理支持设备安装在车辆、经销商和修理设施中至少任意一者上。在这个第一方面，所述再现信息获取装置可以从车辆、经销商和修理设施中至少 任意一者获取所述再现信息；或者，所述再现信息获取装置可以从车辆、经销商和修理设施 中至少任意一者获取表明在所述车辆的修理或部件更换之后所述车辆的车辆状态的修理 后车辆信息，然后可以根据所获取的修理后车辆信息来判定所述故障是否已经再现，从而 获取所述再现信息。在这个第一方面，失效诊断信息产生设备可以还包括修理支持信息产生装置，用 于根据发生新故障时获取的故障时车辆信息并根据所述指令信息而产生修理支持信息，所 述修理支持信息可用于针对所述新故障进行修理或部件更换。在这个第一方面，所述修理支持信息可以包含下列至少任意一者表明要实施的 修理或部件更换的内容的信息，以及表明所述新故障的原因的根源原因信息。本发明的第二方面提供了一种车辆修理支持设备，其安装在车辆、经销商以及修 理设施中的至少任意一者处。这种车辆修理支持设备包括指令信息获取装置，用于从根据
6该第一方面的失效诊断信息产生设备获取指令信息；故障时车辆信息获取装置，用于获取 故障时车辆信息，所述故障时车辆信息表明在车辆中发生故障时检测到的车辆状态；修理 支持信息输出装置，用于根据所获取的故障时车辆信息和所获取的指令信息而产生并输出 修理支持信息，所述修理支持信息可用于针对所述故障而进行的修理或部件更换。本发明的第三方面提供了一种车辆修理支持设备，其安装在车辆、经销商以及修 理设施中的至少任意一者处。这种车辆修理支持设备包括修理支持信息输出装置，用于从 根据该第一方面的失效诊断信息产生设备获取并输出所述修理支持信息。在这个第三方面，所述修理支持信息可以包含下列至少任意一者表明要实施的 修理或部件更换的内容的信息，以及表明所述新故障的原因的根源原因信息。本发明的第四方面提供了一种车辆修理支持系统。该车辆修理支持系统包括根 据该第一方面的失效诊断信息产生设备；根据第二或第三方面的车辆修理支持设备。本发明的第五方面提供了一种失效诊断信息产生系统。该失效诊断信息产生系统 包括根据该第一方面的失效诊断信息产生设备，以及再现信息提供设备。所述再现信息提 供设备包括修理后车辆信息获取装置，用于获取修理后车辆信息，所述修理后车辆信息表 明在车辆的修理或部件更换之后，所述车辆的车辆状态；判定装置，用于根据所获取的修理 后车辆信息来判定所述故障是否已经再现；传送装置，用于根据由所述判定装置判定的结 果而产生所述再现信息，并将所产生的再现信息传送到所述失效诊断信息产生设备。在这个第五方面，可以仅在所述判定装置判定为所述故障尚未再现时，所述传送 装置才将与尚未再现的故障有关的修理信息和故障时车辆信息传送给所述失效诊断信息 产生设备，并且，对所述修理信息和故障时车辆信息的传送可以起到所述再现信息的作用。在这个第五方面，所述修理后车辆信息获取装置、所述判定装置和所述传送装置 可以被安装在车辆、经销商和修理设施中的至少任意一者处。本发明的第六方面提供了一种再现信息提供设备。所述再现信息提供设备可以被 用在根据第五方面的失效诊断信息产生系统中。本发明的第七方面提供了一种失效诊断信息产生方法。该失效诊断信息产生方法 包括获取修理信息，所述修理信息表明伴随车辆的故障而实施的修理或部件更换的内容， 或表明所述故障的原因；获取故障时车辆信息，所述故障时车辆信息表明发生所述故障时 所检测到的车辆状态；获取再现信息，所述再现信息表明在所述车辆的修理或部件更换之 后，所述故障是否已经再现；并且当根据所述再现信息而判定为所述故障尚未再现时，根据 所述修理信息和所述故障时车辆信息而产生指令信息，所述指令信息可用于未来的修理或 部件更换。本发明的第八方面提供了一种数据库。所述数据库保持由根据该第一方面的失效 诊断信息产生设备所提供的所述指令信息。本发明的第九方面提供了一种数据库，其安装在车辆、经销商和修理设施中的至 少任意一者处。所述数据库保持由根据该第一方面的失效诊断信息产生设备所供应的所述 指令信息。根据本发明的这些方面，可以提供失效诊断信息产生设备、失效诊断信息产生系 统等，它们能够通过对车辆的修理或部件更换之后故障是否再现进行判定，来制成仅有各 条可靠信息的数据库。


下面参考附图对本发明的示例性实施例进行的详细说明将阐述本发明的特征、优 点、以及技术上和产业上的重要性，附图中相同的标号表示相同的元素，其中图1的功能构造图示出了根据本发明各种实施例的车辆修理支持系统1的基本功 能；图2的功能构造图示出了根据本发明各种实施例的车辆修理支持系统1的基本功 能；图3的系统构造图示出了根据本发明第一实施例的车辆修理支持系统的有关构 造；图4A和图4B的流程图示出了由根据第一实施例的车辆修理支持系统实现的失效 诊断支持方案的流程；图5是示出FFD示例的图；图6是示出DTC示例的图；图7是示出挖掘指令数据示例的图；图8的图示出了使用挖掘指令数据的挖掘方法的示例；图9是示出了挖掘结果示例的图；图10的系统构造图示出了根据本发明第二实施例的车辆修理支持系统的有关构 造；图IlA和图IlB的流程图示出了由根据第二实施例的车辆修理支持系统实现的失 效诊断支持方案的流程；图12的系统构造图示出了根据本发明第三实施例的车辆修理支持系统的有关构 造；图13A和图13B的流程图示出了由根据第三实施例的车辆修理支持系统实现的失 效诊断支持方案的流程；图14的系统构造图示出了根据本发明第四实施例的车辆修理支持系统的有关构 造；图15A和图15B的流程图示出了由根据第四实施例的车辆修理支持系统实现的失 效诊断支持方案的流程。
具体实施例方式下面将参考附图对本发明的实施例进行说明。图1的功能构造图示出了根据本发明各种实施例的车辆修理支持系统1的基本功 能。车辆修理支持系统1主要包括车内装置201、中心服务器301和经销商终端401。车内 装置201安装在车辆上。中心服务器301布置在挖掘中心(mining center)。经销商终端 401由实施车辆的修理或部件更换的经销商或修理设施(下文中统称为“经销商”)管理。 可以在各个经销商处设置多个经销商终端401。每个经销商终端401通过选定的通信线路 连接到中心服务器301。中心服务器301可以由分散布置在多个位置处的服务器形成；但是 在此情况下，分散布置的服务器在功能上协作以用作一个中心服务器301。注意，与下文将要描述的第二实施例和第三实施例中的情况一样，也可以实现不一定需要经销商终端401 的车辆修理支持系统12和13。图2的功能构造图示出了车辆修理支持系统1的基本功能。车辆修理支持系统1 主要具有修理信息收集功能20、故障时车辆信息收集功能21、指令信息产生功能22、再现 信息收集功能23、指令信息储存功能24和挖掘功能25。修理信息收集功能20收集信息，该 信息表明与车辆的故障相关地实施的修理或部件更换的内容，或者表明故障原因(下文中 统称为“修理信息”)。故障时车辆信息收集功能21收集故障时车辆信息，该信息表明发生 故障时检测到的车辆状态。指令信息产生功能根据伴随同一故障而收集的修理信息和故障 时车辆信息而产生指令信息，所述指令信息可用于未来的修理或部件更换。再现信息收集 功能23获取再现信息，所述再现信息表明车辆的修理或部件更换之后该故障是否已再现。 指令信息储存功能24积累指令信息。只有在车辆的修理或部件更换之后尚未再现过该故障时，指令信息产生功能22 运行以产生指令信息。另一方面，也可以是不管在车辆的修理或部件更换之后是否再现了 故障，指令信息产生功能都运行。在此情况下，只有在车辆的修理或部件更换之后尚未再现 该故障的情况下，才使用所产生的指令信息。如果在车辆的修理或部件更换之后该故障已 经再现，则所产生的指令信息被丢弃。下文中将更详细地描述上述功能20至25。功能20至25的大部分主要分布到中 心服务器301，也分布到各个车辆的车内装置201以及各个经销商处的终端401。图1示出 了功能20至25的布置没有被确定的状态。包括功能20至25的这种布置的车辆修理支持 系统被称为车辆修理支持系统1。功能20至25可以以各种形式实现，下文在第一至第四实 施例中将说明这些布置的一些典型示例。取决于这些功能20至25的布置，根据这些实施 例的车辆修理支持系统分别被称为车辆修理支持系统U至14。车辆修理支持系统11具有第一实施例的布置，使得上述功能20至25主要由中心 服务器301实现。图3的系统构造图示出了车辆修理支持系统11的有关构造。本实施例的车辆修 理支持系统11包括车内装置201、中心服务器301和经销商终端401。车内装置201安装 在车辆上。中心服务器301布置在挖掘中心处。经销商终端401由实施车辆的修理或部件 更换的经销商来管理。如图3所示，每个车内装置201包括各种电子装置202、信息输出装置206和主控 制装置208。主控制装置208通过总线连接到多个车内电子装置202，所述总线例如控制器 局域网(CAN)、体电子区域网(body electronics area network, BEAN，一种双向复用通信 网络)和局部互连网(LIN)。各种电子装置202可以包括各种ECU、传感器等。信息输出装 置206例如是指示器中的灯(用于表示故障的灯)或显示器。中心服务器301包括网络网关302、不定信息数据库303、指令信息数据库304和 信息管理单元305。每个经销商终端401包括信息输出装置402、信息管理单元403和用户接口 406。图4A和图4B的流程图示出了由根据第一实施例的车辆修理支持系统11实现的 失效诊断支持方案的流程。在步骤700，车内E⑶(它们是车辆的车内装置201的各种电子装置202的元件)执行车内装置201的自身故障诊断。车内ECU中的自身故障诊断可以以各种形式来实现， 并可以采用所选的合适方法。当车内E⑶检测到自身故障(例如由车内E⑶监管的系统中 的故障)时，相应的车内E⑶向主控制装置208发送警告信号。在步骤702，车辆的车内装置201的主控制装置208响应于从车内E⑶中任一者发 送的警告信号，使信息输出装置206的警告灯(通常是指示器中的指示器灯)点亮或闪烁， 所述车内E⑶是各种电子装置202的元件。在步骤704，意识到警告灯闪烁的车辆用户主动地将车辆驾驶到经销商处并要求 经销商检查和修理。在步骤706，经销商处的服务人员使用工具601 (见图3)从车辆获取冻结帧数据 (FFD)、诊断故障代码(DTC)和识别信息。工具601通常由汽车制造商提供给各个经销商。工具601假定由经销商处的技术 服务人员使用，并可以是能够由操作人员携带的紧凑终端。注意，工具601可能需要认证 (例如密码输入或ID检查)来使用，以防止未经授权的人员使用工具601。当工具601被 连接到为车辆提供的预定连接终端时，工具601从车辆获取FFD、DTC和识别信息。工具601 可以通过无线通信(例如窄带通信)来获取各条信息。FFD是多条信息，它们表明故障发生时检测到的车辆状态。FFD可以包含各种电子 装置202的工作状态或由传感器检测的时间序列值(的样式)。另外，FFD可以包含各种 各样的信息，例如失效(故障)发生的时候、发生之前和发生之后的运行数据(系统和构成 系统的电子部件的运行数据和/或冻结帧数据)，以及当时的车辆位置和车辆速度。例如， FFD可以包含图5所示的各条信息。DTC是表明警告信号(诊断信息)类型的信息，并且例如可以包含如图6所示的各 条信息。识别信息是车辆识别信息，并且例如可以是车底盘号(body frame number) 0在步骤708，经销商终端401的信息管理单元403将步骤706中由工具601获取的 FFD、DTC和识别信息发送到中心服务器301作为挖掘源数据，还发送挖掘请求信号。注意， 挖掘源数据和挖掘请求信号可以从工具601直接传递到中心服务器301。在步骤710，中心服务器301的信息管理单元305根据从经销商终端401提供的挖 掘源数据中的DTC来确定该故障是否是挖掘目标。例如，信息管理单元305访问指令信息 数据库304，以判定指令信息数据库304中是否存在与当前的DTC对应的那条挖掘指令数 据。注意，从数据库开始积累数据(例如本系统的运行刚刚开始之后)起的短时间长度内 也可能发生一条与当前的DTC对应的挖掘指令数据也没有的情况。下面的说明指的是故障 是挖掘目标的情况。如果故障不是挖掘目标，则中心服务器301可以向经销商终端401提 供此时不可挖掘的通知。在此情况下，在经销商处，服务人员通过所选的方法来识别故障的 根源原因来修理该车辆，然后在修理之后执行下文将描述的步骤720。在步骤712，中心服务器301的信息管理单元305根据从经销商终端401供应的挖 掘源数据来获取FFD的特性量(FFD特性量)。FFD特性量可以包含FFD的时间序列数据中 的特性变动或这些变动的样式。例如，在图5所示FFD的情况下，信息管理单元305获取各 自从时间2到时间3改变的发动机负载、进气管绝对压力、发动机转速、氧气传感器输出以 及空气一燃料比的信息。在步骤714，中心服务器301的信息管理单元305从指令信息数据库304中的挖掘指令数据提取与当前获取的FFD特性量最接近的各条数据，并评估与挖掘指令数据相伴随 的各条根源原因信息，按接近程度的降序作为与当前故障相对应的根源原因信息的候选。这里，挖掘指令数据被用来从FFD导出根源原因信息(表明故障根源原因的信 息)，如何产生该挖掘指令数据将在下文中描述。挖掘指令数据被产生，使得与根源原因信 息对应的FFD特性量由参数(例如图7所示)来表示。图7所示挖掘指令数据例如表明 当根源原因信息表明A传感器系统的故障时，FFD特性量出现在发动机负载、进气管绝对压 力、发动机转速、氧气传感器输出、空气一燃料比和环境温度中。在图5所示FFD的情况下，当FFD特性量由参数表示时，FFD特性量具有由图8中 的A表示的列所示的样式。在此情况下，如图8所示，最接近的FFD特性量对应于A传感器 系统的根源原因信息。第二接近的FFD特性量对应于B切换系统的根源原因信息。第三接 近的FFD特性量对应于D致动器的根源原因信息。因此，如图9所示，A传感器系统的失效、 B切换系统的失效、D致动器的失效以上述顺序被评估为根源原因信息的候选。在步骤716，中心服务器301的信息管理单元305向发出挖掘请求的经销商终端 401发送针对根源原因信息的、经过评估的候选(挖掘结果)。在步骤718，经销商终端401的信息管理单元403通过信息输出装置402输出从中 心服务器301所接收的挖掘结果。信息输出装置402例如是显示器。在此情况下，挖掘结 果被显示在信息输出装置402上。经销商处的服务人员参照挖掘结果来实施修理。此时， 修理被实施到消除故障为止。但是如下文所述，随着指令信息数据库304中积累挖掘指令 数据，挖掘结果的准确性增大。这提高了修理的可靠性(即修理之后故障再现的可能性降 低)，因此防止了下述情况不能识别故障的根源原因，造成车辆的修理花费很长时间。在步骤720，经销商终端401的信息管理单元403向中心服务器301发送指令源数 据。指令源数据包含与当前通过修理而消除的故障相伴随的一组挖掘源数据和根源原因信 息。注意，该挖掘源数据已被发送到中心服务器301(参见步骤708)。这样，与当前通过修 理而消除的故障相伴随的根源原因信息可以被发送到中心服务器301，使得该根源原因信 息可以与已经发送的挖掘源数据相关联。另外，步骤720中发送的根源原因信息是由服务 人员(或服务人员的助理、经理等，这对于以下的说明也适用)通过用户接口 406向经销商 终端401输入的。在步骤720中，当挖掘结果所教导的根源原因信息(包括候选)不合适时，即当 从修理发现根源原因与所教导的根源原因信息不同时，所发现的根源原因信息被发送到中 心服务器301。另外，下述情况也可行当由挖掘结果教导的根源原因信息(尤其是第一候 选)合适时，该根源原因信息也被发送到中心服务器301。在步骤722，中心服务器301的信息管理单元305在不定信息数据库303中临时储 存步骤720中从经销商终端401接收的指令源数据。注意，临时储存的指令源数据最初被 置于不定状态，在该指令源数据被置于确定状态之前，该指令源数据不被用来产生挖掘指 令数据，如下文中将要描述的那样。在步骤724中，中心服务器301的信息管理单元305确定当前的修理之后同一车 辆中是否已经再现过同一故障，并且在尚未再现过同一故障时将该车辆的指令源数据改变 到确定状态。另一方面，当同一故障已再现过的时候，信息管理单元305从不定信息数据库 303删除(丢弃)该车辆的该指令源数据。
在步骤724，每次发生故障时，必要的情况下信息管理单元305可以使用从车辆发 送的挖掘源数据(参见步骤708)来判定该故障是否已再现。例如，当信息管理单元305接 收了挖掘数据源数据时，信息管理单元305在不定信息数据库303搜索指令源数据，该指令 源数据具有与挖掘源数据的识别信息和DTC相同的识别信息和DTC。作为搜索的结果，当不 存在具有相同识别信息和DTC的指令源数据时，信息管理单元305判定该故障是新的。另 一方面，作为搜索的结果，当存在具有相同识别信息和DTC的指令源数据时，信息管理单元 305判定该故障已再现。另外，下述情况也是可行的在步骤724中，信息管理单元305例如在从修理起定 期实施的周期性检查时从车内装置201和/或经销商终端401获取检查结果，并根据所获 取的检查结果来判定故障是否已再现。另外，在步骤724，信息管理单元305有利获取与前次修理的日期和时间或里程有 关的信息(在此情况下，这些条信息被容纳在挖掘源数据中)，并判定当从前次修理起经过 了预定时间长度T (天数)时为止或当车辆行驶了预定距离L(km)时为止故障是否已再现。 在此情况下，也可以是这样的情况在当从前次修理起经过了预定时间长度T (天数)时为 止或当车辆行驶了预定距离L(km)时为止，信息管理单元305没有接收到与不定信息数据 库303中的指令源数据相同的识别信息和DTC的情况下，管理单元305将相应的指令源数 据改变到确定状态。该预定时间长度T(天数)和预定距离(L)可以大体上与修理后为进 行确定而实施的周期性检查的时机相关联，并且可以根据修理或故障的内容而改变。在步骤726，中心服务器301的信息管理单元305只使用不定信息数据库303中 临时储存的指令源数据中的确定指令源数据来产生挖掘指令数据。信息管理单元305在指 令信息数据库304中储存所产生的挖掘指令数据，以将该数据用于将来的挖掘(参见步骤 710至716)。注意，即使在产生了挖掘指令数据时，用于产生该挖掘指令数据的确定指令源 数据仍然可以储存在不定信息数据库303中。在步骤726，可以采用从指令源数据产生挖掘指令数据的各种方法，并可以从这些 不同方法中选择合适的方法。例如，挖掘指令数据可以是指令源数据自身。或者，可以产生 挖掘指令数据，使得(确定状态下的)指令源数据的FFD特性量由参数表示，然后这些参数 被与根源原因信息相关联，如图7所示。这里，图7所示挖掘指令数据示出参数“1”表明 FFD中响应于故障而经历了特性(变动)的条目，而参数“0”表明FFD中并未响应于故障而 经历特性(变动)的条目。在步骤726，当不定信息数据库303中临时储存的一条指令源数据被置于确定状 态时，信息管理单元305可以根据确定状态的这一条指令源信息而产生挖掘指令数据。或 者，也可以共同使用具有同一根源原因信息的多条(确定状态的)指令源数据来产生挖掘 指令数据。在后一种情况下，也可以是在积累了具有同一根源原因数据的预定数目条确定 状态的指令源数据时，产生与该根源原因信息对应的挖掘指令信息。另外，在这后一种情况 下，也可以是每次新添加了具有同一根源原因信息的、确定状态的指令源信息时，通过共 同使用到那时为止获取的具有同一根源原因信息的多条(确定状态的)指令源数据来产生 (更新)挖掘指令数据。另外，在这后一种情况下，也可以是只使用与相同型号的车辆、装 有相同系统的车辆、或者同一目的地的车辆相伴随、并具有同一根源原因信息的多条确定 状态的指令源数据来产生与该根源原因信息相对应的挖掘指令数据。在此情况下，与此对应，挖掘也使用与类似型号的车辆相关的挖掘指令数据等。根据如上所述的第一实施例，可以具体获得如下的有利效果。根据该第一实施例，如上所述，向中心服务器301发送的指令源数据被用来产生 挖掘指令数据，所述挖掘指令数据是在对故障是否已再现进行判定之后的将来挖掘(以及 基于这些挖掘结果的修理)所用的。即，只有在修理之后故障没有再现的情况下，向中心 服务器301发送的指令源数据才被用来产生挖掘指令数据。如果在修理之后故障已经再 现，则该指令源数据被丢弃而不使用该数据。这样，根据该第一实施例，通过考虑故障的再 现，可以只使用准确的指令源数据产生挖掘指令数据。因此，改善了挖掘指令数据的可靠性 (准确性)，因此改善了挖掘结果的可靠性(准确性)。车辆修理支持系统12具有第二实施例的布置，使得上述功能20至25像第一实施 例的情况一样主要由中心服务器301来实现。第一实施例与第二实施例之间的差异在于， 在第一实施例中，挖掘请求是从经销商那方发起的；而在第二实施例中，挖掘请求是从车辆 那方发起的。图10的系统构造图示出了车辆修理支持系统12的有关构造。相同的标号表示与 第一实施例中相同的部件，并将在合适之处略去其说明。如图10所示，每个车内装置201包括各种电子装置202、通信单元204、信息输出 装置206和主控制装置208。中心服务器301包括网络网关302、不定信息数据库303、指令 信息数据库304和信息管理单元305。每个经销商终端401包括信息管理单元403和用户 接口 406。图IlA和图IlB的流程图示出由根据第二实施例的车辆修理支持系统12实现的 失效诊断支持方案的流程。在步骤800，车内E⑶(它们是车辆的车内装置201的各种电子装置202的元件) 执行车内装置201的自身故障诊断。当车内ECU检测到自身故障时，这些车内ECU向主控 制装置208发送警告信号。在步骤802，车辆的车内装置201的主控制装置208响应于从车内E⑶中任一者发 送的警告信号，使信息输出装置206的警告灯(通常是指示器中的指示器灯)点亮或闪烁， 所述车内E⑶是各种电子装置202的元件。在步骤804，车辆的车内装置201的主控制装置208产生挖掘源数据和识别信息， 然后通过通信单元204向中心服务器301发送挖掘请求信号和所产生的挖掘源数据，所述 挖掘源数据包含结合当前警告信号而获取的FFD和DTC。在步骤806，中心服务器301的信息管理单元305根据从车内装置201供应的挖掘 源数据中的DTC，来确定该故障是否是挖掘目标。例如，信息管理单元305访问指令信息数 据库304，以确定指令信息数据库304中存在与当前的DTC对应的那条挖掘指令数据。在本 实施例中下面的说明指故障是挖掘目标的情况。如果故障不是挖掘目标，则中心服务器301 可以向车辆的车内装置201发送不可挖掘的通知。接收到该通知，则车内装置201的主控 制装置208可以通过信息输出装置206向用户提供不可挖掘的通知。在此情况下，当接收 该通知的用户将车辆驾驶到经销商处时，服务人员可以通过选定的方法识别该故障的根源 原因以在经销商处修理该车辆，然后在修理之后执行下文所述的步骤818。在步骤808，中心服务器301的信息管理单元305根据从车内装置201供应的挖掘源数据来获取FFD特性量。步骤808中的处理可以与针对上述第一实施例中图4A的步骤 712所述的处理类似。在步骤810，中心服务器301的信息管理单元305从指令信息数据库304中的挖 掘指令数据提取与当前获取的FFD特性量最接近的那些条数据，并评估与挖掘指令数据相 伴随的各条根源原因信息，按接近程度的降序作为与当前故障相对应的根源原因信息的候 选。步骤810的处理可以与针对上述第一实施例中图4A的步骤714所述的处理类似。在步骤812中，中心服务器301的信息管理单元305向发出该挖掘请求的车辆的 车内装置201发送用于该根源原因信息的经过评估的候选(挖掘结果)。注意，提醒车辆用 户修理车辆的信息和/或建议经销商为止的信息等也可以与挖掘结果一起被发送到车辆 的车内装置201。随着挖掘结果等以这种方式被发送到车内装置201，主控制装置208通过 信息输出装置206 (例如显示器)输出这些挖掘结果等(见图9)。注意，这些挖掘结果也可 以被供应给位于经销商处的经销商终端401，所述经销商是从经销商终端401发出请求时 车辆被驾驶去修理的地方。在步骤814，看到这些挖掘结果的车辆用户主动地将车辆驾驶到经销商并请求经 销商检查和修理。此时，用户向经销商处的服务人员出示那些被输出到信息输出装置206 上的挖掘结果，以便修理。在步骤816，经销商处的服务人员参照这些挖掘结果来实施修理。此时，修理被实 施到消除故障为止。但是如下文所述，随着指令信息数据库304中积累挖掘指令数据，挖掘 结果的准确性增大。这提高了修理的可靠性，因此防止了下述情况不能识别故障的根源原 因，造成车辆的修理花费很长时间。在步骤818，经销商终端401的信息管理单元403向中心服务器301发送指令源数 据。指令源数据包含与当前通过修理而消除的故障相伴随的指令源数据，该数据包含挖掘 源数据和根源原因信息。注意，该挖掘源数据已被发送到中心服务器301 (参见步骤804)。 这样，与当前通过修理而消除的故障相伴随的根源原因信息可以被发送到中心服务器301， 使得该根源原因信息可以与已经发送的挖掘源数据相关联。另外，步骤818中发送的根源 原因信息是由服务人员通过用户接口 406向经销商终端401输入的。或者，根源原因信息 可以从车内装置201发送到中心服务器301，使得该根源原因信息可以与已经发送的挖掘 源数据相关联。在此情况下，根源原因信息可以由该服务人员通过车内装置201的用户接 口(未示出)而输入，也可以由用户通过车内装置201的用户接口(未示出)而输入。注 意，在此情况下，经销商处的经销商终端401不是必需的，因此经销商终端401可以被略去。在步骤818，当由挖掘结果所教导的根源原因信息(包括候选)不合适时，即当由 修理发现该根源原因与所教导的根源原因信息不同时，所发现的根源原因信息被发送到中 心服务器301。另外，也可以是当由挖掘结果所教导的根源原因信息(尤其是第一候选) 合适时，该根源原因信息也被发送到中心服务器301。在步骤820，中心服务器301的信息管理单元305将步骤818中从经销商终端 401 (或车内装置201)接收的指令源信息临时储存在不定信息数据库303中。注意，临时储 存的指令源信息最初被置于不定状态，在该指令源数据被置于确定状态之前，该指令源数 据不用来产生挖掘指令数据，如下文所述。在步骤822，中心服务器301的信息管理单元305确定当前的修理之后同一车辆中是否已经再现过同一故障，并且在尚未再现过同一故障时将该车辆的指令源数据改变到确定状态。另一方面，当同一故障已再现过的时候，信息管理单元305从不定信息数据库303 删除(丢弃)该车辆的该指令源数据。步骤822中的处理可以与针对上述第一实施例中图 4B的步骤724所述的处理类似。在步骤824，中心服务器301的信息管理单元305只使用不定信息数据库303中 临时储存的指令源数据中的确定指令源数据来产生挖掘指令数据。信息管理单元305在指 令信息数据库304中储存所产生的挖掘指令数据，以将该数据用于将来的挖掘(参见步骤 806至812)。步骤824中的处理可以与针对上述第一实施例中图4B的步骤726所述的处 理类似。根据上述第二实施例，与上述第一实施例中的情况一样，只使用准确的指令源数 据产生挖掘指令数据。因此，改善了挖掘指令数据的可靠性(准确性)，因此改善了挖掘结 果的可靠性(准确性)。车辆修理支持系统13具有第三实施例的布置，使得上述功能20至24像第一实施 例的情况一样主要由中心服务器301来实现。第三实施例与第一实施例之间的差异在于， 挖掘功能25主要在车辆那方实现。图12的系统构造图示出了车辆修理支持系统13的有关构造。相同的标号表示与 第一实施例中相同的部件，并将在合适之处略去其说明。如图12所示，每个车内装置201包括各种电子装置202、通信单元204、信息输出 装置206、主控制装置208和信息数据库(DB) 210。信息数据库210储存通过从中心服务器 301下载而获取的挖掘指令数据，如下文所述那样。中心服务器301包括网络网关302、不 定信息数据库303、指令信息数据库304和信息管理单元305。每个经销商终端401包括信 息管理单元403和用户接口 406。图13A和图13B的流程图示出由根据第三实施例的车辆修理支持系统13实现的 失效诊断支持方案的流程。在步骤900，车内E⑶(它们是车辆的车内装置201的各种电子装置202的元件) 执行车内装置201的自身故障诊断。当车内ECU检测到自身故障时，这些车内ECU向主控 制装置208发送警告信号。在步骤902，车辆的车内装置201的主控制装置208响应于从车内E⑶中任一者发 送的警告信号，使信息输出装置206的警告灯(通常是指示器中的指示器灯)点亮或闪烁， 所述车内E⑶是各种电子装置202的元件。在步骤904，车辆的车内装置201的主控制装置208向中心服务器301发送结合当 前警告信号而获取的FFD和DTC，并发送挖掘请求信号。这些条信息(尤其是DTC和识别信 息)在中心服务器301被用来确定故障的再现(见步骤922)。这样，在当前的DTC是从未 经历过的新类型DTC时，主控制装置208可以略去向中心服务器301的发送。在步骤906，车辆的车内装置201的主控制装置208根据结合当前警告信号而获取 的DTC来确定该故障是否是挖掘目标。例如，主控制装置208访问信息数据库210，以判定 信息数据库210中是否存在与当前的DTC对应的那条挖掘指令数据。在本实施例中，下面 的说明指的是故障是挖掘目标的情况。如果故障不是挖掘目标，则主控制装置208可以通 过信息输出装置206向用户提供不可挖掘的通知。在此情况下，当用户将车辆驾驶到经销商处时，服务人员通过所选的方法来识别故障的根源原因来在经销商处修理该车辆，然后 在修理之后执行下文将描述的步骤918。在步骤908，车辆的车内装置201的主控制装置208获取与伴随当前警告信号而获 取的FFD中的FFD特性量有关的信息。步骤908中的处理可以与针对上述第一实施例中图 4A的步骤712所述的处理类似。在步骤910，车辆的车内装置201的主控制装置208从信息数据库210中的挖掘指 令数据提取与当前获取的FFD特性量最接近的各条数据，并评估与挖掘指令数据相伴随的 各条根源原因信息，按接近程度的降序作为与当前故障相对应的根源原因信息的候选。步 骤910中的处理可以与针对上述第一实施例中图4A的步骤714所述的处理类似，只是用车 辆那方的信息数据库210中的挖掘指令数据代替了中心服务器301那方的指令信息数据库 304。在步骤912，车辆的车内装置201的主控制装置208通过信息输出装置206 (例如 显示器)输出这些挖掘结果(对根源原因信息的候选进行评估的结果)等(见图9)。在步骤914，看到这些挖掘结果的车辆用户主动地将车辆驾驶到经销商并请求经 销商检查和修理。此时，用户向经销商处的服务人员出示那些被输出到信息输出装置206 上的挖掘结果。在步骤916，经销商处的服务人员参照这些挖掘结果来实施修理。此时，修理被实 施到消除故障为止。但是如下文所述，随着指令信息数据库304中积累挖掘指令数据(并 且信息数据库210中因而积累挖掘指令)，挖掘结果的准确性增大。这提高了修理的可靠 性，因此防止了下述情况不能识别故障的根源原因，造成车辆的修理花费很长时间。在步骤918，经销商终端401的信息管理单元403向中心服务器301发送指令源 数据。指令源数据包含与当前通过修理而消除的故障相伴随的根源原因信息和挖掘源数据 (伴随当前警告信号而获取的识别信息和FFD、DTC)。注意，该挖掘源数据已被发送到中心 服务器301 (参见步骤904)。这样，与当前通过修理而消除的故障相伴随的根源原因信息可 以被发送到中心服务器301，使得该根源原因信息可以与已经发送的挖掘源数据相关联。另 外，步骤918中发送的根源原因信息是由服务人员通过用户接口 406向经销商终端401输 入的。或者，根源原因信息可以从车内装置201发送到中心服务器301，使得该根源原因信 息可以与已经发送的挖掘源数据相关联。在此情况下，根源原因信息可以由该服务人员通 过车内装置201的用户接口(未示出)而输入，也可以由用户通过车内装置201的用户接 口(未示出)而输入。注意，在此情况下，经销商处的经销商终端401不是必需的，因此经 销商终端401可以被略去。在步骤918，当由挖掘结果所教导的根源原因信息(包括候选)不合适时，即当由 修理发现该根源原因与所教导的根源原因信息不同时，所发现的根源原因信息被发送到中 心服务器301。另外，也可以是当由挖掘结果所教导的根源原因信息(尤其是第一候选) 合适时，该根源原因信息也被发送到中心服务器301。在步骤920，中心服务器301的信息管理单元305将步骤918中从经销商终端 401 (或车内装置201)接收的指令源信息临时储存在不定信息数据库303中。注意，临时储 存的指令源信息最初被置于不定状态，在该指令源数据被置于确定状态之前，该指令源数 据不用来产生挖掘指令数据，如下文所述。
在步骤922，中心服务器301的信息管理单元305确定当前的修理之后同一车辆中 是否已经再现过同一故障，并且在尚未再现过同一故障时将该车辆的指令源数据改变到确 定状态。另一方面，当同一故障已再现过的时候，信息管理单元305从不定信息数据库303 删除(丢弃)该车辆的该指令源数据。步骤922中的处理可以与针对上述第一实施例中图 4B的步骤724所述的处理类似。在步骤924，中心服务器301的信息管理单元305只使用不定信息数据库303中 临时储存的指令源数据中的确定指令源数据来产生挖掘指令数据。信息管理单元305在指 令信息数据库304中储存所产生的挖掘指令数据，以将该数据用于将来的挖掘(参见步骤 906至912)。步骤924中的处理可以与针对上述第一实施例中图4B的步骤726所述的处 理类似。在步骤926，车辆的车内装置201的主控制装置208从中心服务器301下载指令 信息数据库304中储存的挖掘指令信息。主控制装置208在信息数据库210中储存所下载 的挖掘指令数据，以将该数据用于将来的挖掘(参见步骤906至912)。注意，挖掘指令数 据可以响应于来自车辆那方的请求从中心服务器301那方通过下载而供应到车辆那方，和 /或可以无论是否从车辆那方发出请求都以预定的定时从中心服务器那方通过下载而供应 到车辆那方。在这前一种情况下，例如，在步骤902中接收到警告信号时，主控制装置208 可以访问中心服务器301以下载该挖掘指令数据。在此情况下，用于下载的挖掘指令数据 可以只是与当前警告信号(或DTC)相关的挖掘指令数据。在这后一种情况下，该预定的定 时可以是指令信息数据库304中的挖掘指令数据被更新(改变、添加等)的定时，或者也可 以是固定的定时(例如每一个月)。在这种情况下，从中心服务器301那方下载的挖掘指 令数据也不一定是指令信息数据库304中的全部挖掘指令数据，而可以是指令信息数据库 304中必需的挖掘指令数据。另外，也可以是在步骤926中，主控制装置208使用上述步骤906至912中信息 数据库210中的挖掘指令数据来执行挖掘，并在没有获得准确的挖掘结果时从中心服务器 301下载额外的挖掘指令数据(例如详细的挖掘指令数据)。另外，也可以是在当前故障 不是用于信息数据库210中的挖掘指令数据的挖掘目标(见步骤906)时，类似地从中心服 务器301下载附加的挖掘指令数据(例如详细的挖掘指令数据)。根据上述第三实施例，与上述第一实施例中的情况一样，只使用准确的指令源数 据产生挖掘指令数据。因此，改善了挖掘指令数据的可靠性(准确性)，因此改善了挖掘结 果的可靠性(准确性)。注意，第三实施例可以合适地与上述第一实施例结合实现。例如，考虑到车辆那方 的处理负荷或容量的限制，被下载到信息数据库200中的挖掘指令数据可以被限制在预定 的数据大小。因此如上所述，当发生警告信号时，可以首先根据第三实施例使用信息数据库 210中的挖掘指令数据来执行挖掘。当没有获得准确的挖掘结果时，可以根据第一实施例请 求用中心服务器301那方的指令信息数据库304中的挖掘指令数据产生的挖掘结果。车辆修理支持系统14具有第四实施例的布置，使得上述功能20至24像第一实施 例的情况一样主要由中心服务器301来实现。第四实施例与第一实施例之间的差异在于， 挖掘功能25主要在经销商那方实现。图14的系统构造图示出了车辆修理支持系统14的有关构造。相同的标号表示与第一实施例中相同的部件，并将在合适之处略去其说明。如图14所示，每个车内装置201包括各种电子装置202、信息输出装置206和主控 制装置208。中心服务器301包括网络网关302、不定信息数据库303、指令信息数据库304 和信息管理单元305。每个经销商终端401包括信息输出装置402、信息管理单元403、信息 数据库(DB) 404和用户接口 406。信息数据库404储存通过从中心服务器301下载而获取 的挖掘指令数据，如下文所述那样。图15A和图15B的流程图示出由根据第四实施例的车辆修理支持系统14实现的 失效诊断支持方案的流程。在步骤1000，车内E⑶(它们是车辆的车内装置201的各种电子装置202的元件) 执行车内装置201的自身故障诊断。当车内ECU检测到自身故障时，这些车内ECU向主控 制装置208发送警告信号。在步骤1002，车辆的车内装置201的主控制装置208响应于从车内E⑶中任一者 发送的警告信号，使信息输出装置206的警告灯(通常是指示器中的指示器灯)点亮或闪 烁，所述车内E⑶是各种电子装置202的元件。在步骤1004，意识到警告灯闪烁的车辆用户主动地将车辆驾驶到经销商处并要求 经销商检查和修理。在步骤1006，经销商处的服务人员使用工具601 (见图14)从车辆获取FFD、DTC 和识别信息。工具601通常由汽车制造商提供给各个经销商。工具601假定由经销商处的 技术服务人员使用，并可以是能够由操作人员携带的紧凑终端。注意，工具601可能需要认 证(例如密码输入或ID检查)来使用，以防止未经授权的人员使用工具601。当工具601 被连接到为车辆提供的预定连接终端时，工具601从车辆获取FFD、DTC和识别信息。工具 601可以通过无线通信(例如窄带通信)来获取各条信息。在步骤1008，经销商终端401的信息管理单元403将步骤1006中由工具601获取 的FFD、DTC和识别信息发送到中心服务器301。注意，FFD、DTC和识别信息可以从工具601 直接发送到中心服务器301。这些条信息(尤其是DTC和识别信息)被用来在中心服务器 301中确定故障的再现(见步骤1024)。因此，在当前的DTC是从未经历过的新类型嘎DTC 时，向中心服务器301进行的发送可以被略去。在步骤1010，经销商终端401的信息管理单元403根据与当前警告信号相伴随而 获取的DTC来确定该故障是否是挖掘目标。例如，信息管理单元403访问经销商终端401 中的信息数据库404，以判定信息数据库404中是否存在与当前的DTC对应的那条挖掘指令 数据。在本实施例中，下面的说明指的是故障是挖掘目标的情况。如果故障不是挖掘目标， 则信息管理单元403可以通过信息输出装置402向经销商处的服务人员提供此时不可挖掘 的通知。在此情况下，在经销商处，服务人员通过所选的方法来识别故障的根源原因来修理 该车辆，然后在修理之后执行下文将描述的步骤1020。在步骤1012，经销商终端401的信息管理单元403获取与当前警告信号相伴随地 获取的FFD的FFD的特性量有关的信息。步骤1012中的处理可以与针对上述第一实施例 中图4A的步骤712所述的处理类似。在步骤1014，经销商终端401的信息管理单元403从信息数据库404中的挖掘指 令数据提取与当前获取的FFD特性量最接近的各条数据，并评估与挖掘指令数据相伴随的各条根源原因信息，按接近程度的降序作为与当前故障相对应的根源原因信息的候选。步 骤1014的处理可以与针对上述第一实施例中图4A的步骤714所述的处理类似，只是用经 销商那方的信息数据库404中的挖掘指令信息代替了中心服务器301那方的指令信息数据 库 304。在步骤1016，经销商终端401的信息管理单元403通过信息输出装置402 (例如显 示器)输出挖掘结果(对于根源原因信息的候选进行评估的结果)(见图9)。在步骤1018，经销商处的服务人员参照挖掘结果来实施修理。此时，修理被实施到 消除故障为止。但是如下文所述，随着指令信息数据库304中积累挖掘指令数据(并且信 息数据库404中因而积累挖掘指令数据)，挖掘结果的准确性增大。这提高了修理的可靠 性，因此防止了下述情况不能识别故障的根源原因，造成车辆的修理花费很长时间。在步骤1020，经销商终端401的信息管理单元403向中心服务器301发送指令源 数据。指令源数据包含与当前通过修理而消除的故障相伴随的根源原因信息和挖掘源数据 (与当前警告信号相伴随地获取的识别信息和FFD、DTC)。注意，该挖掘源数据已被发送到 中心服务器301 (参见步骤1008)。这样，与当前通过修理而消除的故障相伴随的根源原因 信息可以被发送到中心服务器301，使得该根源原因信息可以与已经发送的挖掘源数据相 关联。另外，步骤1020中发送的根源原因信息是由服务人员通过用户接口 406向经销商终 端401输入的。在步骤1020中，当挖掘结果所教导的根源原因信息(包括候选)不合适时，即当 从修理发现根源原因与所教导的根源原因信息不同时，所发现的根源原因信息被发送到中 心服务器301。另外，下述情况也可行当由挖掘结果教导的根源原因信息(尤其是第一候 选)合适时，该根源原因信息也被发送到中心服务器301。在步骤1022，中心服务器301的信息管理单元305在不定信息数据库303中临时 储存步骤1020中从经销商终端401接收的指令源数据。注意，临时储存的指令源数据最初 被置于不定状态，在该指令源数据被置于确定状态之前，该指令源数据不被用来产生挖掘 指令数据，如下文中将要描述的那样。在步骤1024中，中心服务器301的信息管理单元305判定当前的修理之后同一车 辆中是否已经再现过同一故障，并且在尚未再现过同一故障时将该车辆的指令源数据改变 到确定状态。另一方面，当同一故障已再现过的时候，信息管理单元305从不定信息数据库 303删除(丢弃)该车辆的该指令源数据。步骤1024中的处理可以与针对上述第一实施例 中图4B的步骤724所述的处理类似。在步骤1026，中心服务器301的信息管理单元305只使用不定信息数据库303中 临时储存的指令源数据中的确定指令源数据来产生挖掘指令数据。信息管理单元305在指 令信息数据库304中储存所产生的挖掘指令数据，以将该数据用于将来的挖掘(参见步骤 1010至1016)。步骤1026中的处理可以与针对上述第一实施例中图4B的步骤726所述的 处理类似。在步骤1028，经销商终端401的信息管理单元403从中心服务器301下载指令信 息数据库304中储存的挖掘指令数据。信息管理单元403在信息数据库404中储存所下载 的挖掘指令数据，以将该数据用于将来的挖掘(参见步骤1010至1016)。注意，挖掘指令 数据可以响应于来自经销商终端401那方的请求从中心服务器301那方通过下载而供应到经销商终端401那方，和/或可以无论是否从经销商终端401那方发出请求都以预定的定 时从中心服务器301那方通过下载而供应到中心服务器401那方。在这前一种情况下，例 如，在步骤1002中接收到警告信号时，经销商终端401的信息管理单元403可以访问中心 服务器301以下载该挖掘指令数据。在此情况下，用于下载的挖掘指令数据可以只是与当 前警告信号(或DTC)相关的挖掘指令数据。在这后一种情况下，该预定的定时可以是指令 信息数据库304中的挖掘指令数据被更新(改变、添加等)的定时，或者也可以是固定的定 时(例如每一个月)。在这种情况下，从中心服务器301那方下载的挖掘指令数据也不一定 是指令信息数据库304中的全部挖掘指令数据，而可以只是指令信息数据库304中必需的 挖掘指令数据。另外，也可以是在步骤1028中，经销商终端401的信息管理单元403使用上述 步骤1010至1016中信息数据库404中的挖掘指令数据来执行挖掘，并在没有获得准确的 挖掘结果时从中心服务器301下载额外的挖掘指令数据(例如详细的挖掘指令数据)。另 外，也可以是在当前故障不是用于信息数据库404中的挖掘指令数据的挖掘目标(见步 骤1010)时，类似地从中心服务器301下载附加的挖掘指令数据(例如详细的挖掘指令数 据)。根据上述第四实施例，与上述第一实施例中的情况一样，只使用准确的指令源数 据产生挖掘指令数据。因此，改善了挖掘指令数据的可靠性(准确性)，因此改善了挖掘结 果的可靠性(准确性)。注意，第四实施例可以合适地与上述第一实施例结合实现。例如，考虑到经销商终 端401那方的处理负荷或容量的限制，信息数据库404中储存的挖掘指令数据的数据大小 可以受到限制。因此如上所述，当发生警告信号时，可以首先根据第四实施例使用信息数 据库404中的挖掘指令数据来执行挖掘。当没有获得准确的挖掘结果时，可以根据第一实 施例请求用中心服务器301那方的指令信息数据库304中的挖掘指令数据所产生的挖掘结^ ο上文详细描述了本发明的这些实施例；但是本发明的各个方面不限于上述实施 例。本发明的各个方面也可以被实现为使得在不脱离本发明范围的情况下，向上述实施例 施加各种变更或代替。例如，在上述实施例中，构成挖掘指令信息的根源原因信息表明故障的原因(根 源原因)。代替根源原因信息或者除了根源原因信息之外，根源原因信息也可以采用与根源 原因信息相伴随的其他条信息。例如，代替根源原因信息或者除了根源原因信息之外，也可 以使用表明消除该故障所用的修理的内容(包括部件更换的内容)的信息。另外，在上述实施例中，用于根源原因信息的候选被作为挖掘结果而输出。代替根 源原因信息或者除了根源原因信息之外，挖掘结果也可以包含与根源原因信息相伴随的其 他条信息。例如，代替根源原因信息或者除了根源原因信息之外，也可以输出表明消除与该 根源原因信息相伴随的故障所用的以往修补内容(包括以往部件更换的内容)的信息作为 挖掘结果。另外，在上述实施例中，在故障尚未再现时产生挖掘指令数据。或者，也可以不管 故障是否再现都产生挖掘指令数据。但是在此情况下，所产生的挖掘指令数据受到限制性 管理，使得只有在故障尚未再现的情况下才将该挖掘指令数据用于失效诊断。即，在判定为故障尚未再现之前，所产生的挖掘指令数据被作为临时挖掘指令数据来对待。在此情况下， 在上述第一和第二实施例中，禁止临时挖掘指令数据用于挖掘。在上述第三和第四实施例 中，禁止临时挖掘指令数据下载或禁止其用于车内装置201和/或经销商终端401处的挖 掘(如果已下载)。另外，在上述实施例中，主要根据DTC来判定同一故障是否已再现。或者，也可以 根据其他条信息(例如FFD等)来判定故障是否已再现，并可以对判定故障再现所用的信 息进行选择。另外，在上述实施例中，不定信息数据库303被布置在中心服务器301那方，不管 故障是否再现，指令源数据都被发送到中心服务器301 ；但是，本发明的各个方面不限于这 种构造。例如也可以是这样的情况指令源数据被临时储存在车内装置201和/或经销商 终端401中，并且仅在故障尚未再现时，该临时储存的指令源数据才被发送到中心服务器 301。即，不定信息数据库303的功能可以由车内装置201和/或经销商终端401来实现。 在此情况下，中心服务器301的信息管理单元305可以在指令源数据从车内装置201和/ 或经销商终端401供应的时候判定同一故障是否尚未再现，以根据所供应的指令源数据来 产生挖掘指令数据。即，在这种情况下，从车内装置和/或经销商终端401供应指令源数据 被用作表明故障尚未再现的信息。或者，可以向中心服务器301发送具有冗余信息的指令 源信息，该冗余信息表明故障尚未再现。另外，上述实施例描述了这样的示例A传感器系统的失效、B开关系统的失效和D 致动器的失效作为根源原因信息的候选。或者，用作候选的根源原因信息也可以是更低级 别的根源原因信息(例如A传感器系统中某具体部分的失效等)，或者可以是更高级别的根 源原因信息(例如包括D致动器的E系统或E功能的失效等)。另外，在上述实施例中，考虑了上述故障的再现来产生挖掘指令数据。这样，根据 挖掘指令而获得的挖掘结果(尤其是第一候选)的准确性应当较高。如果即使在根据这些 挖掘结果而实施修理的情况下同一故障再现，则可以丢弃得出这些挖掘结果所用的挖掘指 令数据(以及产生这些挖掘指令数据所依据的确定状态指令源数据)。另外，在上述实施例中，中心服务器301的部分功能或全部功能可以由车内装置 201来实现。例如，中心服务器301可以被移走或保留，同时中心服务器301的全部功能可 以由专门车辆的车内装置201来实现。在此情况下，该专用车辆实际上用作移动式中心服 务器。另外，例如，中心服务器301可以被移走或保留，同时中心服务器301的全部功能可 以由多个车辆的车内装置201中的每一者来实现。在此情况下，可以通过车辆间通信等用 信息来产生挖掘指令数据。另外，所产生的挖掘指令数据可以不仅用来识别宿主车辆的故 障的根源原因信息，而且用来识别其他车辆的故障的根源原因信息。尽管已经参考本发明的示例性实施例对其进行了说明，但是应当明白本发明不限 于所述的这些实施例或构造。相反，本发明应当认为覆盖了各种变更形式和等效布置。另 外，尽管以各种示例性组合和构造的方式示出了本发明的各个要素，但是其他组合和构造 (包括更多的、更少的或仅单一的要素)也在所附权利要求的范围内。
权利要求
1.一种失效诊断信息产生设备，其特征在于包括修理信息获取装置，用于获取修理信息，所述修理信息表明伴随车辆的故障而实施的 修理或部件更换的内容，或表明所述故障的原因；故障时车辆信息获取装置，用于获取故障时车辆信息，所述故障时车辆信息表明发生 所述故障时所检测到的车辆状态；指令信息产生装置，用于根据所述修理信息和所述故障时车辆信息而产生指令信息， 所述指令信息可用于未来的修理或部件更换；以及再现信息获取装置，用于获取再现信息，所述再现信息表明在所述车辆的修理或部件 更换之后，所述故障是否已经再现，其中，当根据所述再现信息而判定为在所述车辆的修理或部件更换之后所述故障尚未 再现时，所述指令信息产生装置根据与尚未再现的所述故障有关的修理信息和故障时车辆 信息而产生指令信息，或者判定将由所述指令信息产生装置根据与尚未再现的所述故障有 关的修理信息和故障时车辆信息而产生的指令信息用于未来的修理或部件更换。
2.根据权利要求1所述的失效诊断信息产生设备，其中，在判定为到从所述车辆的修 理或部件更换开始经过了预定时间长度时为止或者到所述车辆行驶了预定距离时为止所 述故障尚未再现时，所述指令信息产生装置根据与尚未再现的所述故障有关的修理信息和 故障时车辆信息而产生指令信息，或者判定将由所述指令信息产生装置根据与尚未再现的 所述故障有关的修理信息和故障时车辆信息而产生的指令信息用于未来的修理或部件更 换。
3.根据权利要求1或2所述的失效诊断信息产生设备，其中，在判定为到从所述车辆的 修理或部件更换开始经过了预定时间长度时为止或者到所述车辆行驶了预定距离时为止 所述故障已经再现时，所述指令信息产生装置不会根据与尚未再现的故障有关的修理信息 和故障时车辆信息而产生指令信息，或者判定不将由所述指令信息产生装置根据与尚未再 现的故障有关的修理信息和故障时车辆信息而产生的指令信息用于未来的修理或部件更 换。
4.根据权利要求1所述的失效诊断信息产生设备，其中仅在判定为到从所述车辆的修理或部件更换开始经过了预定时间长度时为止或者到 所述车辆行驶了预定距离时为止所述故障尚未再现时，所述修理信息获取装置才获取与尚 未再现的所述故障有关的修理信息，并且所述故障时车辆信息获取装置才获取所述故障时 车辆信息；并且所述指令信息产生装置根据所获取的修理信息和故障时车辆信息而产生指令信息。
5.根据权利要求3所述的失效诊断信息产生设备，其中，在判定为到从所述车辆的修 理或部件更换开始经过了预定时间长度时为止或者到所述车辆行驶了预定距离时为止所 述故障已经再现时，所述指令信息产生装置丢弃与已经再现的故障有关的修理信息和故障 时车辆信息，并且在已经产生了与已经再现的故障有关的指令信息时丢弃与已经再现的故 障有关的指令信息。
6.根据权利要求1-5中任一项所述的失效诊断信息产生设备，其中，仅在判定为到从 所述车辆的修理或部件更换开始经过了预定时间长度时为止或者到所述车辆行驶了预定 距离时为止所述故障尚未再现时，所述指令信息产生装置才将与尚未再现的故障有关的指令信息提供给车辆修理支持设备，所述车辆修理支持设备安装在车辆、经销商和修理设施 中至少任意一者上。
7.根据权利要求1所述的失效诊断信息产生设备，其中，所述再现信息获取装置从车 辆、经销商和修理设施中至少任意一者获取所述再现信息；或者，所述再现信息获取装置从 车辆、经销商和修理设施中至少任意一者获取表明在所述车辆的修理或部件更换之后所述 车辆的车辆状态的修理后车辆信息，然后根据所获取的修理后车辆信息来判定所述故障是 否已经再现，从而获取所述再现信息。
8.根据权利要求1所述的失效诊断信息产生设备，还包括修理支持信息产生装置，用 于根据发生新故障时获取的故障时车辆信息并根据所述指令信息而产生修理支持信息，所 述修理支持信息可用于针对所述新故障进行修理或部件更换。
9.根据权利要求8所述的失效诊断信息产生设备，其中，所述修理支持信息包含下列 至少任意一者表明要实施的修理或部件更换的内容的信息，以及表明所述新故障的原因 的根源原因信息。
10.一种车辆修理支持设备，安装在车辆、经销商以及修理设施中的至少任意一者处， 所述车辆修理支持设备的特征在于包括指令信息获取装置，用于从根据权利要求6所述的失效诊断信息产生设备获取指令信息；故障时车辆信息获取装置，用于获取故障时车辆信息，所述故障时车辆信息表明在车 辆中发生故障时检测到的车辆状态；以及修理支持信息输出装置，用于根据所获取的故障时车辆信息和所获取的指令信息而 产生并输出修理支持信息，所述修理支持信息可用于针对所述故障而进行的修理或部件更 换。
11.一种车辆修理支持设备，安装在车辆、经销商以及修理设施中的至少任意一者处， 所述车辆修理支持设备的特征在于包括修理支持信息输出装置，用于从根据权利要求8所述的失效诊断信息产生设备获取并 输出所述修理支持信息。
12.根据权利要求10或11所述的车辆修理支持设备，其中，所述修理支持信息包含下 列至少任意一者表明要实施的修理或部件更换的内容的信息，以及表明所述新故障的原 因的根源原因信息。
13.—种车辆修理支持系统，其特征在于包括根据权利要求6所述的失效诊断信息产生设备；以及根据权利要求10-12中任一项所述的车辆修理支持设备。
14.一种失效诊断信息产生系统，包括根据权利要求1所述的失效诊断信息产生设备，以及再现信息提供设备，其特征在于所述再现信息提供设备包括修理后车辆信息获取装置，用于获取修理后车辆信息，所 述修理后车辆信息表明在车辆的修理或部件更换之后，所述车辆的车辆状态；判定装置，用 于根据所获取的修理后车辆信息来判定所述故障是否已经再现；以及传送装置，用于根据 由所述判定装置判定的结果而产生所述再现信息，并将所产生的再现信息传送到所述失效诊断信息产生设备。
15.根据权利要求14所述的失效诊断信息产生系统，其中，仅在所述判定装置判定为 所述故障尚未再现时，所述传送装置才将与尚未再现的故障有关的修理信息和故障时车辆 信息传送给所述失效诊断信息产生设备，并且，对所述修理信息和故障时车辆信息的传送 起到所述再现信息的作用。
16.根据权利要求14或15所述的失效诊断信息产生系统，其中，所述修理后车辆信息 获取装置、所述判定装置和所述传送装置被安装在车辆、经销商和修理设施中的至少任意 一者处。
17. 一种再现信息提供设备，其特征在于所述再现信息提供设备被用在根据权利要求14至16中任一项所述的失效诊断信息产 生系统中。
18. 一种失效诊断信息产生方法，其特征在于包括获取修理信息，所述修理信息表明伴随车辆的故障而实施的修理或部件更换的内容， 或表明所述故障的原因；获取故障时车辆信息，所述故障时车辆信息表明发生所述故障时所检测到的车辆状态；获取再现信息，所述再现信息表明在所述车辆的修理或部件更换之后，所述故障是否 已经再现；以及当根据所述再现信息而判定为所述故障尚未再现时，根据所述修理信息和所述故障时 车辆信息而产生指令信息，所述指令信息可用于未来的修理或部件更换。
19.一种数据库，其特征在于所述数据库保持由根据权利要求1至9中任一项所述的失效诊断信息产生设备所产生 的所述指令信息。
20.一种数据库，安装在车辆、经销商和修理设施中的至少任意一者处，其特征在于 所述数据库保持由根据权利要求6所述的失效诊断信息产生设备所提供的所述指令信息o
21.一种失效诊断信息产生设备，包括修理信息获取装置，其获取修理信息，所述修理信息表明伴随车辆的故障而实施的修 理或部件更换的内容，或表明所述故障的原因；故障时车辆信息获取装置，其获取故障时车辆信息，所述故障时车辆信息表明发生所 述故障时所检测到的车辆状态；指令信息产生装置，其根据所述修理信息和所述故障时车辆信息而产生指令信息，所 述指令信息可用于未来的修理或部件更换；以及再现信息获取装置，其获取再现信息，所述再现信息表明在所述车辆的修理或部件更 换之后，所述故障是否已经再现，其中，当根据所述再现信息而判定为在所述车辆的修理或部件更换之后所述故障尚未 再现时，所述指令信息产生装置根据与尚未再现的所述故障有关的修理信息和故障时车辆 信息而产生指令信息，或者判定将由所述指令信息产生装置根据与尚未再现的所述故障有 关的修理信息和故障时车辆信息而产生的指令信息用于未来的修理或部件更换。
全文摘要
本发明涉及失效诊断信息产生设备和失效诊断信息产生系统。失效诊断信息产生设备包括修理信息获取单元，其获取修理信息，该信息表明伴随车辆的故障而实施的修理或部件更换的内容或表明故障的原因；故障时车辆信息获取单元，其获取故障时车辆信息，该信息表明发生故障时检测到的车辆状态；指令信息产生单元，其根据修理信息和故障时车辆信息产生指令信息，该信息可用于未来的修理或部件更换；再现信息获取单元，其获取再现信息，该信息表明车辆的修理或部件更换之后故障是否已再现。用再现信息判定修理或部件更换之后故障是否再现。根据判定结果，指令信息产生单元判定是否产生指令信息或是否将所产生的指令信息用于未来的修理或部件更换。
文档编号G07C5/08GK101999140SQ200980112316
公开日2011年3月30日 申请日期2009年4月2日 优先权日2008年4月2日
发明者石川智康 申请人:丰田自动车株式会社