车辆中故障原因的确定的制作方法

文档序号:11133003阅读:376来源:国知局
车辆中故障原因的确定的制造方法与工艺

本发明涉及一种用于确定车辆中故障原因的方法,尤其是经由在车辆外部的服务器中的在线服务自动确定车辆的故障原因的方法。本发明还涉及一种构造为支持服务器中这样的基于在线的故障原因确定的车辆,以及适合于执行所述方法的服务器。



背景技术:

车辆例如轿车或货车,可能由控制设备和传感器例如通过所谓的车载诊断功能报告故障信息。在这种故障信息出现时,却通常不知道实际的原因。例如当作为故障报告了提高的冷却剂温度时,故障原因可能是多种的,例如由于冷却系统中的不密封而缺少冷却液,由于蒸汽出口或者冷却剂泵损坏而缺少液体流通,或者由于前面的车辆负载和天气条件引起的过热。用于确定故障原因的一种可能性例如是对呼叫中心进行呼叫,在那里存储了所谓的故障树,其对问题进行处理。然而这是人员和时间密集的。

在这种情况下,DE 10 2014 105674 A1公开了一种具有车辆控制设备的系统,所述车辆控制设备具有处理器并且与通信装置和车辆显示器通信。控制设备配置为,接收传感器输入,所述传感器输入包含了故障触发和/或在故障触发期间采集的环境相关的数据。控制设备可以通过处理器分析故障触发,以确定故障事件。控制设备可以确定合适的维修点并且将故障事件和环境相关的数据经由通信装置传输到该维修点。控制设备可以配置为,用于接收分析报告和预约请求并且将分析报告和预约请求输出到车辆显示装置。

EP 2 731 085 A1涉及一种电信终端和一种用于支持保养或维修车辆的方法。车辆具有诊断接口并且为车辆分配一个光学可检测的车辆识别信息。诊断接口具有无线接口并且电信终端具有另一个无线接口并且配置为,处理经过诊断接口可调用的以及涉及了车辆状态的信息。移动电信终端具有照相机装置。诊断接口、无线接口和另一个无线接口配置为,将至少一个涉及了车辆状态的信息传输到电信终端。电信终端的照相机设备配置为采集车辆识别信息。借助一方面涉及了车辆状态的信息和另一方面车辆识别信息,可以定义至少一个用于保养或维修车辆的措施。

US 2014/0277902 A1涉及一种对车辆相关的分析进行所谓众包,例如对车辆相关的分析进行海量查询。车辆通常具有计算机,其输出诊断故障代码(英语:Diagnostic Trouble Codes,DTC),所述代码显示了车辆中的故障状态。诊断故障代码(DTC)提示特殊部件的特殊问题,例如,发动机中气缸具有点火中断,然而不提供问题原因的提示并且不建议用于解决该问题的解决方案。由此公开了一种系统,其使用众包原理分析DTC和其他遥测数据,以推荐车辆保养和其他解决方案。

DE 10 2011 076 037 A1涉及一种用于提供车辆诊断服务的系统,其包括诊断单元和控制单元。诊断单元构造为,分析累积存储的诊断故障代码(Diagnostic Trouble Code,DTC),以分析特定车辆的问题历史。控制单元将由车辆的远程信息处理装置接收的DTC与问题历史比较,以确定,车辆中是否存在问题,当确定了车辆中具有问题时向驾驶员通知问题信息,产生控制信号以调整对于与该问题相关的对象的诊断持续时间,并且将控制信号传输到车辆的远程信息处理装置。

DE 102 35 525 A1公开了一种状态监视系统,其在车辆的寿命期间采集多个车辆的动力总成数据(Aggregatdaten)并且存档。该来历数据(Vorgeschichte)可以由车辆识别号、时间戳、载荷谱、直方图、关于时间的数据曲线或由从车载诊断和数据分析功能导出的知识组成。附加地,状态监视采集远程信息处理服务中心、维修点(诊断数据、维修、保养状态)和技术检测部门的诊断和保养数据。“正常的车辆特性”和“有问题的车辆特性”的模式通过在使用机器学习和数据挖掘的方法的条件下处理组合的数据来导出。例如,分析速度、发动机转速、发动机温度、发动机转矩、环境温度、燃料消耗和排放值,以识别正常和异常的特性。利用该模式来匹配和个性化车载系统诊断算法并且其允许在车辆外部对于多种应用进行分析,例如预测即将到来的车辆问题和确定车辆维修状态。



技术实现要素:

由于车辆技术的增加的复杂性,由此对于当在车辆处出现故障时快速和可靠的故障原因确定存在大的需求。

在按照本发明的用于确定车辆中故障原因的方法中车辆外部的服务器接收车辆的故障消息。在车辆中根据车辆的故障状态产生故障消息。故障消息例如可以包括诊断故障代码、所谓的诊断故障码(DTC)(Diagnostic Trouble Code(DTC)),其由车辆的控制设备借助车辆的传感器产生。这样的诊断故障代码例如可以由车辆诊断系统,所谓的车载诊断(OBD),在车辆运行期间提供。在服务器中根据接收的故障消息和车辆的载荷谱数据确定故障原因。替换地或附加地,在服务器中根据故障消息和车辆的车辆状态参量确定故障原因。

也称为负载集的载荷谱数据涉及在车辆的部件或组件处在一个时间段上所有出现的负荷的总体。例如车辆的内燃机的载荷谱可以显示,在哪个时间段上内燃机以何种转速运行或在哪个时间段上输出发动机的何种转矩。载荷谱可以在车辆的运行中对于车辆的不同组件被采集,例如对于内燃机、对于变速箱、对于悬挂系统、制动系统、空调设备或转向助力。载荷谱数据由此说明了一个部件的过去负荷的总数并且其由此也被称为车辆历史的数据。载荷谱数据特别地在车辆中产生故障消息之前被确定并且其从车辆被传输到服务器。

车辆的车辆状态参量涉及当前的参量和测量值,其例如由车辆的传感器采集。车辆状态参量例如可以包括冷却剂温度、发动机温度、车辆速度、发动机转速、发动机转矩、车辆的变速器挂上的档等。服务器将请求传输到车辆,用于确定特定的车辆状态参量并且将所述车辆状态参量传输到服务器。在确定了车辆中期望的车辆状态参量之后,车辆状态参量例如可以自主地从车辆被传输到服务器或由服务器调用。

通过在出现故障消息之后确定故障原因时考虑载荷谱数据,即,车辆的过去的负荷,即所谓的车辆历史,可以以较高的可靠性确定故障原因。通过由车辆将载荷谱数据自动地传输到服务器,可以及时在服务器中自动地进行原因分析,从而可以快速确定和判断故障原因。通过在需要时从服务器请求车辆的附加的车辆状态参量和在确定故障原因时加以考虑,可以以高的精度和快速地自动在服务器中确定故障原因。此外仅传输最小所需数据。

按照一种实施方式,在方法中此外根据客户服务数据确定故障原因。客户服务数据可以包括关于车辆本身的信息,其在过去造访维修点时被确定和保持,例如进行的维修、更换的部件以及客户的抱怨或观察。客户服务数据还可以包括其它车辆的信息,这些信息在对该其它车辆的维修点造访时被确定和记录。特别地,可以考虑结构相同或结构相似的车辆或具有相似生产年限的车辆的客户服务数据。客户服务数据还可以包括在给定的故障消息、载荷谱数据和/或车辆状态参量的情况下的故障原因。客户服务数据由服务器从客户服务数据库中根据故障消息调用。由此支持了故障原因的快速和精确确定。此外可以从客户服务数据中根据确定的故障原因自动地产生维修模式。维修模式例如包括设立所需的备件以消除故障原因和为更换备件而需要的工作位置。此外维修模式可以包括对于维修的成本估计。根据维修模式,维修点可以例如及早规划车辆的维修。

在另一个实施方式中,前面提到的用于确定车辆的故障原因的步骤按照以下顺序进行。首先根据取决于故障消息而从客户服务数据库中调用的客户服务数据,确定故障原因。然后根据故障消息和车辆的载荷谱数据(Lastkollektivdaten)确定故障原因。最后根据故障消息和车辆的故障状态参量确定故障原因。在用于确定故障原因的每个步骤之后可以分别对于相应的故障原因确定当前的品质值。品质值例如说明了,所确定的故障原因就是实际的故障原因并且由此车辆通过消除所确定的故障原因又变得完好或至少充分修复的概率有多高。根据前面进行的故障原因确定的品质值进行故障原因的按照上述顺序的确定。当例如根据客户服务数据对于故障原因,已经确定了故障原因的非常高的品质时,可以省去根据故障消息和载荷谱数据确定故障原因以及根据故障消息和车辆状态参量确定故障原因的步骤。但是如果根据客户服务数据的故障原因的品质值不够高,则根据故障消息和载荷谱数据确定故障原因。如果这里用于确定的故障原因的品质值也不够高,则根据故障消息和车辆状态参量确定故障原因。通过该顺序的工作方式可以将在车辆和服务器,即所谓的后端(Backend)之间的通信最小化。用于相应的故障原因的当前品质值是否已经足够,例如可以借助决策器(Entscheiders)自动地通过将品质值与预先给出的阈值比较来确定。由此最后确定的故障原因,即,具有足够高品质值的故障原因,被从服务器传输到车辆,以便在车辆中输出,例如输出到车辆的驾驶员。故障原因例如可以通过车辆的显示屏输出给驾驶员并且包括附加的信息,例如故障的严重程度,由此例如给出,是否可能继续行驶或车辆是否尽早送到维修点或甚至最好拖到维修点,以避免进一步损坏车辆。此外例如可以将维修模式的至少一些信息输出给驾驶员,从而驾驶员获得关于维修的成本和时间范围的概况。

在另一个实施方式中,前面提到的用于确定故障原因的步骤,即,根据客户服务数据确定故障原因、根据故障消息和车辆的载荷谱确定故障原因和根据故障消息和车辆的车辆状态参量确定故障原因,在时间上并行进行并且根据在相应的步骤中确定的故障原因来确定作为结果的故障原因。当在一个步骤中确定了多个不同的故障原因时,例如可以借助多数规则或通过故障原因的加权来确定作为结果的故障原因。通过至少部分地在时间上并行进行所有前面描述的用于确定故障原因的步骤,可以以大的可靠性和精度确定作为结果的故障原因。通过在时间上并行的实施,可以在较短的时间内确定作为结果的故障原因。

在本发明的另一个实施方式中,故障消息包括诊断故障代码和车辆识别标识。诊断故障代码被分配给故障状态并且包含标号,用于识别在车辆的运行期间可能出现的故障。诊断故障代码也称为诊断故障码(Diagnostic Trouble Code(DTC))。车辆识别标识例如说明了车辆的车辆类型并且此外可能的车辆的特点(Ausstattungsmerkmale)。车辆识别标识例如可以包括车辆单独的号码,例如车辆识别代号(英语:Vehicle Identification Number,VIN),利用其可以唯一地识别车辆。借助车辆识别标识可以简单地从客户服务数据库中确定关于车辆或关于相似车辆的信息。

在另一种实施方式中,在根据故障消息和车辆的载荷谱数据确定故障原因时将车辆的载荷谱数据与出现相同的故障状态的另一辆车的载荷谱比较。如果在该另一辆车中对于该故障状态确定了一个故障原因,则对于从其接收到故障消息的车辆以高的概率也存在相同或相似的故障原因。因为车辆的过去的负荷可能对故障原因具有决定性影响,所以通过考虑在相应的故障消息情况下另一辆车的载荷谱数据,可以以高的概率假定,存在相同的故障原因,从而可以以高的可靠性确定故障原因。

故障消息、载荷谱数据以及车辆状态参量可以经过无线电通信在车辆和服务器之间传输。通过使用无线电通信,在车辆行驶期间就可以在服务器中进行故障原因的确定,从而可以及早确定故障原因并且由此可以例如避免车辆抛锚或车辆中的后续故障。

在本发明的另一个实施方式中,在根据故障消息和车辆状态参量确定故障原因时根据故障消息产生检查计划(Prüfplan)。检查计划构造为,根据车辆的状态参量,可以从故障原因的预定集合中迭代地确定一个故障原因。根据检查计划请求所需的车辆状态参量。检查计划例如可以自动地在服务器中被处理。服务器可以连续地根据检查计划从车辆请求车辆状态参量。由此可以将在服务器和车辆之间的通信开销最小化。

按照本发明还提供一种车辆,其包括处理装置和用于在车辆和车辆外部的服务器之间传输数据的传输装置。处理装置能够根据车辆的故障状态产生故障消息并且将故障消息传输到服务器。故障消息例如可以包括由车辆的控制装置经过例如所谓的车载诊断提供的诊断故障代码(Diagnostic Trouble Code,DTC)。处理装置此外能够特别地在产生车辆中的故障消息之前确定载荷谱数据并且将其从车辆传输到服务器。载荷谱数据例如可以连续地在车辆中被确定并且收集。替换地或附加地,处理装置还能够基于由服务器向车辆的请求在车辆中确定车辆状态参量并且将其从车辆传输到服务器。由此车辆能够结合服务器执行前面描述的方法或其实施方式。由此可以可靠和快速确定车辆中的故障原因。

车辆还包括输出单元,其与处理装置耦合。处理单元可以从服务器借助传输装置接收由服务器确定的故障原因并且经过输出单元输出到车辆使用者。由此可以在车辆中出现故障之后非常短的时间内向车辆使用者通知可能的故障原因。

按照本发明还提供一种服务器,其包括处理装置和用于在服务器和车辆之间传输数据的传输装置。处理装置能够经过传输装置从车辆接收故障消息。故障消息在车辆中根据车辆的故障状态产生。处理装置还能够根据故障消息和车辆的载荷谱数据确定故障原因。载荷谱数据在车辆中产生故障消息之前被确定并且从车辆传输到服务器,例如基于服务器的请求。替换地或附加地,处理单元可以根据故障消息和车辆的车辆状态参量确定故障原因。为此服务器向车辆请求车辆状态参量。在车辆中确定所请求的车辆状态参量并且作为应答传输到服务器。服务器由此适合于执行前面描述的方法或其实施方式并且由此也包括前面描述的优点。

尽管在不同实施方式中描述了方法、车辆和服务器的前面描述的特征,但是这些实施方式可以任意互相组合。

附图说明

以下参考附图详细描述本发明。在此

图1示出了按照本发明的实施方式的车辆和服务器,

图2示意性示出了按照本发明的实施方式用于确定车辆中的故障原因的方法,

图3示意性示出了按照本发明的另一个实施方式用于确定车辆中的故障原因的方法,

图4示出了根据客户服务数据确定故障原因的方法步骤的细节,

图5示出了用于从客户服务数据中产生维修模式的方法步骤的细节,

图6示出了用于根据车辆的载荷谱数据确定故障原因的方法步骤的细节,

图7示出了用于根据车辆状态参量确定故障原因的方法步骤的细节,

图8示意性示出了按照本发明的实施方式的用于确定车辆中的故障原因以及用于预测车辆中的故障情况的方法。

具体实施方式

图1示出了车辆10、服务器20和客户服务数据库KDDB 40。车辆10经过无线电通信30与服务器20相连。无线电通信30例如可以经过电信网路实现,例如GSM或LTE。车辆10包括处理装置11、例如微处理器或控制器,传输装置12和输出单元13。传输装置12例如可以包括发送和接收装置,其能够与服务器20建立无线电通信30,以便在车辆10和服务器20之间传输数据。输出单元13例如可以包括车辆10的仪表板中的显示器,尤其是显示屏,例如导航系统的或车辆10的娱乐系统的显示屏。处理装置11与传输装置12和输出单元13耦合。处理装置11还经过例如车辆总线17与车辆10的控制设备相连,例如与对车辆10的驱动电机15进行控制的发动机控制设备14相连。经过车辆总线17,处理装置11可以与另外的控制装置和车辆10的传感器耦合,以便尤其是从车辆获得诊断信息,即,所谓的车载诊断信息。处理装置11还与存储装置16耦合,在所述存储装置中可以收集处理装置11在车辆10运行期间收集的数据。在存储装置16中存储的数据例如可以包括所谓的载荷谱数据,其包括车辆10的使用和负荷曲线。例如载荷谱数据可以说明,在何种时间段上车辆10的驱动电机15以何种转速或转矩运行。

服务器20包括处理装置21和传输装置22。传输装置22适合于在车辆10和服务器20之间传输数据。服务器20与客户服务数据库40耦合,在所述客户服务数据库中存储了在车辆10或其他车辆造访维修点时采集的客户服务信息。客户服务数据例如可以包括何时更换了车辆10的哪些部件和解决了车辆10的哪个故障的信息。例如在客户服务数据库40中可以存储,在车辆10中由于出现特定的故障消息而确定了特定的故障原因并且然后更换了车辆10的特定部件。

在以下根据不同的例子参考附图2-8详细描述车辆10结合服务器20和客户服务数据库40的工作方式。

车辆10中故障的故障原因的确定在车辆10外部在服务器20中进行。这通过越来越多的车联网实现,例如经过无线电通信30。此外考虑在确定故障之前收集的车辆10本身的信息、来自于客户服务数据库40的信息以及例如由传感器采集的车辆10的当前信息。结合图2,此外建议一种顺序的或迭代的过程。总之,该过程包括分析客户服务数据、分析也称为车辆历史的载荷谱数据的步骤,和引导的在线故障查询。过程步骤的顺序在此取决于在车辆10和服务器20之间必须传输的数据量。当过程步骤不能识别明确的故障原因时,开始下一个过程步骤并且从车辆10询问其他为此所需的数据。

首先,车辆10将故障消息,例如诊断故障代码(Diagnostic Trouble Code,DTC)与车辆识别标识(Vehicle Identification Number,VIN)一起发送到服务器20。故障消息在车辆10中根据车辆10的故障状态产生。例如产生发动机控制设备14的故障消息并且经过处理装置11和传输装置12传输到服务器20。

在服务器20中在第一步骤201中对该故障消息进行客户服务数据的分析。此外从客户服务数据库40中查询客户服务数据并且将客户服务数据从客户服务数据库40发送到服务器20。当基于客户服务数据的分析能够找到故障原因时,在步骤204中将该故障原因传输到车辆10和例如在输出单元13上显示。当例如借助服务器20中的决策器确定了,基于客户服务数据的分析不能找到原因时或不能以足够的可靠性确定原因时,在服务器20中在步骤202中关于接收的故障消息进行车辆历史的分析。为此服务器20查询车辆10的车辆历史。车辆历史,即在车辆10中在数据存储器16中收集的所谓的载荷谱数据,然后从处理装置11经过传输装置12发送到服务器20。基于车辆历史,在服务器20中查找对于所报告的故障的原因。当足够精确地确定了故障原因时,例如由相应的决策器(Entscheider)确定了时,在步骤204中将故障原因传输到车辆10并且在那里例如在显示单元13上输出。如果在步骤202中基于车辆历史也没有确定对于故障消息的合适原因时,则在服务器20中在步骤203中在线启动引导的故障排查。该引导的故障排查例如可以根据检查计划进行,所述检查计划是根据故障消息在服务器20中选择或产生的。检查计划使得可以根据车辆10的当前的状态参量从预先给出的故障原因集合中迭代地确定一个故障原因。为此从车辆10查询在车辆10中确定并且从车辆10发送到服务器2的不同的测量参量。测量参量的该查询和发送可以多次先后对于检查计划的不同步骤进行。决策器又可以确定,借助引导的故障排查所确定的故障原因是否具有足够的质量或品质,以便在步骤204中向车辆使用者或客户输出。如果又不能唯一地或以足够的品质确定故障原因,则在步骤205中继续所述方法,其中例如经过向驾驶员的相应的输出而输出呼叫呼叫中心或预约维修点的建议。

图3示出了基于客户服务数据、车辆历史和引导的故障排查来确定故障原因的替换示例。在图3中示出的例子中过程步骤201至203不是互相相关地先后进行,而是并行进行。为此将车辆10的数据作为输入数据301完全收集并且在服务器20中处理。在服务器20中并行进行引导的故障排查,客户服务数据的分析和车辆历史的分析,并且从每个步骤201至203确定可能的相应故障原因。决策器302例如可以利用确定的故障原因的加权来确定整个故障原因,其在步骤204中被传输到车辆10以用于输出到车辆使用者或客户。当决策器302不能找到明确的故障原因时,在步骤205中将建议输出到车辆使用者,来呼叫呼叫中心或预约维修点。

图4示出了在考虑对例如在图2和3的步骤201中使用的客户服务数据的分析的条件下用于确定故障原因的细节。车辆10将故障消息发送到服务器20,其例如包括诊断故障代码或故障存储记录(DTC)和车辆识别标识,例如车辆识别代号(VIN)。车辆识别代号和故障存储记录的传输在服务器20中起动在线分析,以通过分析客户服务数据识别故障情况的可能解决方案。为此服务器20从客户服务数据库40请求针对相同的DTC的客户服务数据。客户服务数据库40将客户服务数据发送到服务器20并且服务器20适合于基于客户论断和维修点论断的相似性在使用DTC、VIN和其他客户服务数据的条件下产生解决方案假设。例如在客户服务数据内识别在当前的故障情况和已经出现的故障情况之间的相似性,以便在此基础上产生针对当前的故障情况的解决方案假设。然后评估解决方案假设的品质,即,确定的故障原因的品质,并且判断,实际上识别了故障原因还是没有识别。在图5中详细示出对于不同的故障消息(DTC1,DTC2等的假设形成。每个假设包括了相应的车辆数据,例如车辆类型、车载设备、车辆年龄等,描述了故障状态的客户论断,以及维修点论断,例如哪些部件可能存在潜在故障和由此要更换。作为每个假设的结果,可以建立所谓的维修模式,其中包含了为维修故障原因所需的备件和工作位置。基于维修模式,维修点可以例如建立成本概算或在时间上规划车辆的维修。只要假设被看作是可能的故障原因,则维修模式可以被发送到车辆并且在那里由车辆使用者在预约维修点时使用。

图6详细示出了图2和3的步骤202的车辆历史的分析。在车辆10中可以收集负荷状态,例如发动机转速、发动机转矩、制动值、开关状态等,并且以载荷谱的形式存储在存储装置16中。换言之,将车辆的运行中车辆的特定的特征值划分为组或类。特征值的这样的划分也称为分类。关于发动机转速例如可以作为分类或载荷谱存储在存储装置16中,在哪个时间段车辆10的驱动电机15在从1000至1500转的转速范围中运行,在哪个时间段驱动电机15在从1500至2000转每分的转速范围中运行等。对于车辆历史的分析,例如可以将与当前的故障消息(DTC)相关的分类过滤出。该分类从车辆10被传输到服务器20。通过车辆识别代码和历史的车辆特性(分类)的传输可以的是,服务器20识别在相应的故障情况下具有相似的车辆特性的车辆。前提条件是,在服务器中存在其他车辆的相应分类和故障情况。根据减小的分类集合来检测在车辆10的分类和在服务器20中存储的其他车辆的分类之间的相似性。基于所得到的相似的车辆清单,可以在进一步考虑车辆识别代号和诊断故障代码(DTC)的条件下查找客户服务数据,例如与前面在参考图4描述的那样。最后判断,是否识别了故障原因。

图7示出了步骤203的引导的在线故障排查的细节。基于由车辆10接收的诊断故障代码(DTC),服务器20产生检查计划,其使用车辆的测量参量。车辆的测量参量例如可以包括车辆的当前传感器值,例如发动机15的当前转速、冷却剂温度、环境温度、环境空气压力、驱动电机15的涡轮增压器的增压压力等。产生的检查计划在服务器中例如被顺序地处理,其中要考虑其他测量参量。从车辆10请求这些测量参量并且车辆10确定这些测量参量并且将其发回到服务器20。这可以多次重复,从而服务器20按照顺序从车辆10请求多个测量参量并且所述测量参量从车辆10被传输到服务器20。在检查计划末尾确定可能的故障原因,或者可以确定,利用该检查计划不能确定故障原因并且由此在维修点详细检查车辆。

如果从多个车辆收集和提供这些信息,则可以特别有效地利用前面描述的其中将故障存储记录(DTC)和分类从车辆传输到服务器的方法。图8示意性示出了服务器20,其从车队(Fahrzeugflotte)800收集故障存储记录和分类。这些信息可以被使用来确定故障原因,如前面参考图2至图7所述的,或者用于设立车辆中故障情况的预测。在预测时可以将关于车辆的故障可能性的询问发送到服务器。在使用数据库的条件下可以将具体的车辆的历史背景与数据库比较,以便确定具有类似特性的车辆中的故障情况。在类似车辆中的故障例如可以在考虑车辆的里程、由客户描述的车辆的症状,以及分类的条件下被确定。

前面描述的用于确定故障原因的方法使得可以提高故障原因识别率以及在线识别故障原因,从而可以将车辆中的处理开销最小化。此外通过顺序地或迭代地进行故障原因的确定,可以传输最小量的数据,如例如参考图2所述的。故障原因确定的结果可以用于维修点的预调节(Vorsteuerung),如例如参考图5根据维修模式描述的。此外可以通过预测故障情况来避免故障,方式是,在保养的范围内进行相应的预防措施或通过在线改变配置来修理故障。

附图标记列表

10 车辆

11 处理装置

12 传输装置

13 输出单元

14 发动机控制设备

15 驱动电机

16 存储装置

17 车辆总线

20 服务器

21 处理装置

22 传输装置

30 无线电通信

40 客户服务数据库

201 分析客户服务数据

202 分析车辆历史

203 引导的在线故障排查

204 与客户通信

205 呼叫呼叫中心/预约维修点

301 输入数据

302 决策器

800 车队

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1