远程信息处理系统的记录

1.一种远程信息处理系统，包括：
汽车远程信息处理部件；
至少一个处理单元；
至少一个应用部件，提供所述远程信息处理部件的服务，其中所述至少一个应用部件实施于所述至少一个处理单元中，并且被适配成将其状态以记录消息的形式传输至记录器部件；以及
所述记录器部件，实施于处理单元中，并且被适配成接收来自所述至少一个应用部件的所述记录消息，并且基于所接收的记录消息来产生记录文件；
其中所述记录消息包括：
所述至少一个应用部件的部件识别符；
描述所述至少一个应用部件的所述传输状态的消息识别符；
包括至少一个参数的元数据，以及
报告器部件，其实施于处理单元中，并且被适配成将所述记录文件传输至实施于处理单元中的分析器部件，其中所述分析器部件还被适配成通过基于至少一个预定义使用案例来自动分析所传输的记录文件，而执行自动故障根本原因分析。
2.根据权利要求1所述的系统，其中所述记录器部件还被适配成在产生所述记录文件时将所述所接收的记录消息转换成压缩二进制格式。
3.根据权利要求1所述的系统，还包括：
用于存储所产生的记录文件的存储器；并且
所述报告器部件还被适配成从所述存储器中读取以前存储的记录文件。
4.根据权利要求3所述的系统，其中
所述分析器部件实施于外部处理单元中，具体来说包括于供应商服务器中，该供应商服务器还包括非车载储存存储器，或者该分析器部件是车载分析器部件。
5.根据权利要求4所述的系统，其中所述报告器部件被配置成接收来自所述供应商服务器的用于车载分析的触发信号和/或字典解码数据。
6.根据权利要求3所述的系统，其中所述报告器部件还被适配成通过所述远程信息处理系统的无线通讯模块将所述以前存储的记录文件传输至所述分析器部件。
7.根据权利要求3所述的系统，其中所述报告器部件还被适配成在预定时间之后，将所述以前存储的记录文件传输至所述分析器部件，并且所述分析器部件被配置成存储所传输的记录文件。
8.根据权利要求7所述的系统，其中所述预定时间包括2至3天。
9.根据权利要求3所述的系统，其中所述分析器部件还被适配成通过以下步骤分析所述所传输的记录文件：
从存储器中读取多个预定义使用案例；
从所述所传输的记录文件中提取至少一个记录消息；以及
通过将所述至少一个所提取的记录消息与所述至少一个预定义使用案例的至少一个状态匹配，来从所述多个预定义使用案例中识别所述至少一个预定义使用案例；
其中所述至少一个预定义使用案例被定义为在状态流程图中呈现的多个状态和关系。
10.根据权利要求9所述的系统，
其中所述远程信息处理系统的所述至少一个处理单元包括多线程系统，其能够同时执行所述至少一个应用部件的并发实例；
其中所述至少一个预定义使用案例的所述至少一个状态包括至少一个使用案例变量；
以及
其中所述分析器部件还被适配成，通过将包括于所述至少一个记录消息的所述元数据中的所述至少一个参数与所述至少一个使用案例变量匹配，来识别所述至少一个预定义使用案例的实例。
11.根据前述权利要求中任一项所述的系统，其中所述至少一个应用部件还被适配成在接收到来自所述记录器部件的预定触发信号时，将其状态传输至所述记录器部件。
12.根据权利要求9所述的系统，其中所述分析器部件还被适配成，通过应用预定义多级别字典，来将所提取的至少一个记录消息转换成人可读的文本。
13.一种远程信息处理系统的记录方法，包括以下步骤：
将至少一个应用部件的至少一个状态以记录消息的形式传输至记录器部件，所述至少一个应用部件提供远程信息处理部件的服务并且实施于处理单元中；
通过所述记录器部件来接收所述记录消息；以及
基于所接收的记录消息来产生记录文件；
其中所述记录消息包括：
所述至少一个应用部件的部件识别符；
描述所述至少一个应用部件的所传输的至少一个状态的消息识别符；以及包括至少一个参数的元数据；
将所述记录文件传输至实施于处理单元中的分析器部件；以及
通过基于至少一个预定义使用案例来自动分析所传输的记录文件，来执行自动故障根本原因分析。
14.根据权利要求13所述的方法，其中所述记录消息还包括时戳。
15.根据权利要求13所述的记录方法，还包括：
将所产生的记录文件存储于存储器中；
从所述存储器中读取以前存储的记录文件。
16.根据权利要求15所述的记录方法，还包括：
从存储器中读取多个预定义使用案例；
从所述所传输的记录文件中提取至少一个记录消息；
通过将所述至少一个所提取的记录消息与所述至少一个预定义使用案例的至少一个状态匹配，来从所述多个预定义使用案例中识别所述至少一个预定义使用案例；
其中所述至少一个预定义使用案例被定义为在状态流程图中呈现的多个状态和关系；
基于所述至少一个预定义使用案例来获得分析数据；以及
以人可读的格式显示所述分析数据。

远程信息处理系统的记录\n技术领域\n[0001] 本发明涉及用于记录并且诊断远程信息处理系统（telematics system）的方法和设备，所述方法和设备将来自实时跟踪方法的特征与持续误差存储和诊断组合，其中所记录并且分析的系统可主要由任意数量的展现显著相互依赖性的子部件组成。\n背景技术\n[0002] 自从1978年由Simon Nora和Alain Minc引进以来，远程信息处理，即电信和信息学的整合已经变得非常普及，尤其在汽车远程信息处理的情况下，即在车辆中的应用非常普及。汽车远程信息处理系统的典型应用包括使用全球定位系统技术的汽车导航系统、在车辆到车辆和车辆到基础设施环境中的车用紧急报警系统、在车辆事故或故障情况下的紧急呼叫系统、集成式免提移动电话、无线安全通讯、自动驾驶辅助系统、移动数据、收音机和电视机和车辆追踪，例如作为车队管理系统的一部分，但是不限于这些。远程信息处理系统可包括电子器件、电机和电磁装置。智能车辆技术用于车辆之间或车辆与外部传感器或外部服务器之间的安全和商业通讯。\n[0003] 汽车远程信息处理领域最新添加的一个产品是提供与车辆的远程信息处理部件互动的车用车载记录和车载诊断系统。当前车辆系统采用‘车载诊断系统’以便在早期检测车辆部件的问题。所检测到的问题报告给驾驶员。另外，一般记录下这些问题，以便稍后专家使用诊断故障码(DTC)来分析。通常，这就允许了车辆一返回供检查，服务供应商就更迅速地识别问题原因。通常，扫描工具用于读取诊断信息存储器。为此目的，扫描工具一般实体上连接至车载诊断系统。\n[0004] 追踪如汽车远程信息处理系统的复杂产品的系统状态，以及尽可能早地检测问题行为的能力是预防严重车辆事故以及确保(接近)无问题产品生命周期的关键。具体来说，如例如用于在车辆事故或故障情况下自动发送紧急呼叫或用于在车辆和/或后端服务器之间交换关于危险道路条件的信息的安全相关远程信息处理部件的故障需要尽快检测或理想情况下通过不断监测所涉及的远程信息处理部件和/或(软件)应用部件来预期。随着现今远程信息处理系统的复杂性增加和电子部件的集成不断发展，与至今仍是汽车工业中的车载诊断标准化努力的核心的单独硬件诊断比较，所涉及(软件)应用部件的故障的记录、诊断和校正已经变得更重要。\n[0005] 系统过程和活动通常通过汽车环境中的(软件)应用部件或通过与所述部件的互动来执行，并且通常主要由彼此互动的子部件所执行的很多子任务来组成。在许多情况下，必须考虑到子系统的组合行为以便在系统故障的情况下正确识别误差的根本原因。此外，过程经常在有误差的情况下展现不稳定行为，即，系统问题可由于外部条件的变化而自行恢复。这类系统的特定实例是可能会在没有网络覆盖的条件下失败但是一旦达到网络覆盖区域就立刻恢复的在线和连接系统。\n[0006] 自动诊断工具需要能够考虑到这些特性以便避免不确定的结果。在不稳定系统中，不仅需要提取已经发生的相关误差，而且需要提供关于总体系统可靠性和性能的信息(例如，成功完成使用案例（case）相对于失败使用案例的数量)。由于涉及应用部件和远程信息处理部件的复杂系统中的许多误差并非与安全相关并且可能另外为不稳定的，因此需要使远程信息处理系统的检修与标准车辆检查周期断开联系。具体来说，由要求驱动的远程信息处理系统的检修，理想情况下在客户投诉之前，是为了客户和服务供应商的利益。\n[0007] 此外，当前车辆中的远程信息处理系统的复杂性和互连性增加导致越来越大量的可能误差、根本原因和误差消息，由此迅速地超出车载诊断系统和受过训练的诊断专家的能力，在许多情况下这些诊断专家需要通过运行诊断测试作为车辆服务的一部分来‘亲手’诊断发生的问题。标准化误差码或诊断故障码可能有帮助，但是在高度竞争环境中经常阻碍技术进步。考虑到车辆的相当长的产品生命周期(与如例如智能手机相反)，以及所部署远程信息处理系统的系统升级的有限能力，与当前更具有刚性的解决方案相反，真正可扩展的记录和诊断系统也是合乎需要的。\n发明内容\n[0008] 通过远程信息处理系统来解决上文所述的技术问题，所述系统包括：\n[0009] 汽车远程信息处理部件；\n[0010] 至少一个处理单元；\n[0011] 至少一个应用部件，其提供远程信息处理部件的服务，其中至少一个应用部件实施于至少一个处理单元中并且被适配成将其呈记录消息的形式的状态传输至记录器部件；\n以及\n[0012] 记录器部件，其实施于处理单元中并且被适配成接收来自至少一个应用部件的记录消息并且基于所接收的记录消息来产生记录文件。\n[0013] 如上所述，远程信息处理系统基于电信和信息学并且可包括很多远程信息处理部件，其中一些或所有部件可彼此互动以便提供许多服务至用户或其它系统或系统部件。在本发明的情形中，具体来说，远程信息处理系统可为汽车远程信息处理系统，即，部署于例如汽车、卡车、飞机、火车或船舶的交通工具中的远程信息处理系统。具体来说，汽车远程信息处理系统可部署于汽车中。\n[0014] 远程信息处理系统包括至少一个汽车远程信息处理部件，但是可包括具有任意水平的互连性的任意数量的汽车远程信息处理部件。在本文中，汽车远程信息处理部件通常为安装于车辆中的硬件部件，但是还可包括实施于单个或多个处理单元中的软件应用部件。典型汽车远程信息处理部件可选自但是不限于包括以下的群组：汽车机头单元、汽车收音机、汽车音响系统，包括一个或多个扬声器、放大器和D/A转换器、麦克风系统，包括一个或多个麦克风和A/D转换器、车辆导航装置、GPS(全球定位系统)装置、一个或多个辅助输入装置，如触摸屏、鼠标、控制杆、轨迹球等、一个或多个传感器，如压力传感器、道路条件传感器、停车传感器、光传感器等、实施以前提到或其它功能性的任何电子控制装置(ECU)、动力总成控制模块(PCM)、一个或多个存储媒体，如硬盘驱动器(HDD)、光存储器装置、RAM存储器等、CD和/或DVD播放机、无线路由器、WiFi收发器、一个或多个USB连接器、具有蓝牙天线的蓝牙收发器、具有USB连接器和/或(蓝牙)收发器的一个或多个辅助装置、调制解调器(例如GSM、GPRS、UMTS等无线连接调制解调器)、多频带天线、卫星天线、移动终端，如移动电话、智能手机、PDA、平板电脑、笔记本型个人计算机或类似装置。特定的部件间互连(如汽车网络CAN、MOST等)或一般互连技术(如乙太网路或USB)还可在实现车辆内的特定远程信息处理功能中发挥重要作用。远程信息处理系统的可能部件的更详细说明进一步在下文给出。\n[0015] 汽车远程信息处理部件通常提供一个或多个特定服务至用户和/或远程信息处理系统的另一个部件。具体来说，服务可经由远程信息处理系统的至少一个应用部件提供至用户和/或其它部件。应用部件可通过电子电路来提供，但是通常实施为处理单元中的软件应用部件。具体来说，在处理单元执行应用部件与由车辆的其它部件预先定义的时标同步发生的意义上，应用部件可为实时应用部件。举例来说，更新导航系统的显示通常与车辆的移动和车辆GPS位置的检测到的变化同步发生。处理单元可为任何种类的电子处理装置，具体来说，如用于嵌入系统中的CPU或GPU，并且实行方案可呈一组计算机可执行指令或程序代码形式。用于实施和/或运行处理单元上的应用部件的指令集或程序代码可存储在如本领域中已知的易失性或非易失性存储器和/或存储装置中，并且可在安装于远程信息处理系统中时被配置、由用户来定制，和/或经由远程信息处理系统的外部输入来更新。具体来说，此处和下文的用户是指驾驶员、乘客或机械工或其它专家。处理单元和/或存储器和/或存储装置可为中央远程信息处理控制单元(TCU)的一部分或可为汽车远程信息处理部件的一部分。这类远程信息处理部件的实施例在下文进一步的发明详述中给出。\n[0016] 应用部件提供的远程信息处理部件的服务包括但是不限于来自以下群组的服务：\n信息娱乐服务，如免提电话、导航、音频服务，如AM/FM收音机、数字音讯广播(DAB)收音机、带内同频(IBOC)数字收音机和卫星收音机、视频服务，如DVD回放、HDD回放、数字视频广播(DVB)视频服务、3GPP移动视频服务等、网络访问、电子邮件服务、交通信息服务和人机互动(HMI)服务，如车载游戏和可浏览车辆信息服务或需要车辆到基础设施通讯的任何其它应用类服务，以及与道路和车辆安全相关的服务，如自动紧急呼叫(E呼叫)、自动故障呼叫(B呼叫)、自动服务呼叫(S呼叫)、车载诊断，例如根据EOBD(欧洲车载诊断)或OBD-II(车载诊断-II)条例的车载诊断、引擎控制服务、安全服务，例如连接至汽车闭锁系统的安全服务，以及车辆到车辆和车辆到基础设施报警。服务可由单个或多个远程信息处理部件的单个应用部件提供，其中远程信息处理部件可彼此和/或与应用部件互动。具体来说，应用部件可向特定远程信息处理部件请求服务，如经由蓝牙连接器来发送紧急呼叫，并且特定远程信息处理部件(在此情况下为蓝牙连接器)在与其它远程信息处理部件(例如蓝牙天线和移动终端)的互动的情况下提供所请求的服务。服务还可由用于单个或多个远程信息处理部件的多个应用部件来提供。\n[0017] 在此处和下文中，应用部件提供远程信息处理部件的服务是指应用部件经由软件和/或硬件远程信息处理部件来提供服务。为此目的，应用部件可将呈控制信号形式的服务请求发送至远程信息处理部件，接收来自远程信息处理部件的状态信息，并且发送数据至远程信息处理部件和/或接收来自远程信息处理部件的数据。远程信息处理部件可进一步依赖于另一个远程信息处理部件来提供所请求的服务，并且因此可以类似于应用部件与远程信息处理部件互动的方式而首先与另一个远程信息处理部件互动。类似地，应用部件可依赖于另一个应用部件来提供服务，并且因此可以类似于应用部件的方式而首先与另一个应用部件互动。以此方式，可形成多个远程信息处理部件和/或多个应用部件的链接以便提供服务。在此类链接中，每个部件，不论为应用部件或远程信息处理部件，都可将消息、信号和数据馈送给链接中的下一个部件，潜在地在对其进行处理之后。然而，应用部件还可与多个远程信息处理部件互动以便提供单个服务，并且多个应用部件可与单个远程信息处理部件互动以便提供单个或多个服务。除了部件的线性链接以外，部件的树状链接可为可能的。\n在这类情况下，消息、信号和数据基于相应部件的预定标准而发送至树中的下一个部件或后续部件。最终，每个链接可具有至少一个部件充当整个链接的‘控制器’并且提供服务至用户或另一个远程信息处理部件。\n[0018] 提供远程信息处理部件的服务的至少一个应用部件可确定其状态，然后将其呈记录消息的形式的状态传输至记录器部件。此处和下文的状态表示部件所处的条件，具体来说，相对于所提供的服务所处的条件，即将要由部件提供的服务的特定部分。典型条件可包括‘活动’、‘空闲’和‘失败’和具体得多的条件如‘由于管道断开未能下载文件’、‘已经停滞\n5分钟’、‘没有足够电池功率’、‘在收音机-夹钳=断开时禁止、只在点火时允许’、‘当前无网络条件’等取决于特定服务、特定部件和其与其它部件的关系。总之，确定部件的状态形成提供相对于特定服务或功能的描述性记录消息的基础，并且因此通常涉及相应部件的相应检查和状态标志。相对于通过自动故障根本原因分析来进行的误差检查(进一步参见下文)，具体来说，状态可包括部件的误差状态，即在发生具体误差之后部件所处的具体状态。\n应用部件可由于处理单元执行相应指令或程序代码和/或基于从另一个应用部件和/或远程信息处理部件(具体来说，从对应于所提供的服务的部件链接中的部件)接收的状态信息来确定状态。当基于所接收的状态信息来确定状态时，应用部件可应用预定义规则来处理所接收的状态信息。这些规则的一部分可为决策树，以用于确定作为状态信息来接收的所报告的误差是否为关键的、非关键的或不相关的。另外，状态信息中所含的误差报告可涉及硬件失败，具体来说，所涉及远程信息处理部件的硬件失效，和/或软件故障，即，所涉及应用部件的软件故障。如果一旦误差已经发生就不能提供服务，误差可视为关键的。如果一旦误差已经发生，仍然可提供服务，但是例如与规定相比处于较慢速度，误差可视为非关键的。另外，如果误差不影响服务的成功提供也不影响服务的质量，例如通过在不产生额外费用或延迟的情况下连接至并非所请求的电信供应商的另一电信供应商，误差可视为不相关的。\n[0019] 记录器部件可实施于与至少一个应用部件相同的处理单元中或不同处理单元中。\n具体来说，记录器部件可实施于中央处理单元中，而至少一个应用部件可实施于分配至或集成于汽车远程信息处理部件中的处理单元中。记录器部件可直接接收来自至少一个应用部件的记录消息，具体来说，如果记录器部件和至少一个应用部件实施于同一处理单元中或经由在本领域中已知的有线或无线连接(例如，经由CAN、MOST或IEEE1394总线(参见下文))来接收。记录器部件可基于所接收的记录消息来产生记录文件，方法是通过仅产生记录文件并且将相应记录消息的数据结构写入所产生的记录文件或通过将相应记录消息附加至现有记录文件。取决于藉以得到记录消息的应用部件，记录器部件可进一步将记录消息写入不同记录文件。为此目的，记录器部件可包括文件管理部件或甚至数据库。\n[0020] 所描述的本发明系统提供没有任何特殊设备的复杂汽车系统的特别车载记录能力。通过记录提供服务的(软件)应用部件的故障，通常可以有效方式来检测更频繁的软件误差(如与硬件误差相比)。间接地，基于软件中产生的信号，在某些情况下也可识别硬件中的缺陷，其中针对相应软件远程信息处理部件的无故障功能来解译硬件的状态。由于记录器部件可连续地处理应用部件的成功或失败，因此还可捕获并且诊断不稳定行为，如由对于网络覆盖的依赖性所触发的行为，这对于采用标准系统检查并且通常只在车辆启动时或在检查车辆期间执行一次的本领域的诊断系统来说几乎是不可能的。所产生的记录文件以紧凑和集中的方式来积累相关记录信息并且可容易地进行后处理以便诊断系统的潜在问题。所产生的记录文件也充当证明文件，甚至相对于法律方面的证明文件，例如，当确定重要系统(如紧急呼叫发送器)为什么会失败时。与在本领域中已知的DTC的依赖性过滤相比，对应于存储在记录文件中的记录消息的事件的固有发生率排序显著改进确定故障根本原因的机会。\n[0021] 在一个或多个实施方案中，记录消息可包括：\n[0022] 至少一个应用部件的部件识别符；\n[0023] 描述至少一个应用部件的传输状态的消息识别符；以及\n[0024] 包括至少一个参数的元数据。\n[0025] 记录消息可由至少一个应用部件以包括上述数据字段的预定义、编码、可能二进制的格式来产生。预定义记录格式的目标是传输所有有关信息，同时最大限度地减少数据量。为此目的，所提供方法可以类似于DTC(诊断故障码)协议码的方式来使用码以及参数和描述，但是所提供记录协议的格式不同于DTC格式。码可稍后翻译成可读文本(参见下文)。\n可由特定应用部件传输的记录消息可例如由相应应用部件的供应商来预先定义，并且通常可由部件识别符和消息识别符或所识别的信号来唯一地识别，其中消息/信号识别符描述应用部件的传输状态。每个记录消息可进一步包括元数据，如一个或多个参数。为了获得一系列明确定义的消息，每个记录消息可进一步包括时戳。可能标准帧格式可如下：\n[0026] 时戳  部件ID  消息/信号ID  元数据\n[0027] 应注意，信号ID可能已经带有关于起始部件的元信息，即，应用部件或汽车远程信息处理部件的元信息；在一些情况下，此信息可能足以识别并且分析使用案例，如下文进一步描述。具体来说，在协议方面，信号ID可指示应用部件产生的系统事件或协议消息，例如，成功连接至移动网络。在编程语言方面，信号ID可与方法的执行相关，所述方法触发相应软件系统内的事件或一系列事件，即所涉及的应用部件链接。部件ID指示启始此信号的应用部件或远程信息处理部件，例如，网络控制器。通过将两个标识符结合，部件ID和信号ID唯一地识别根据本发明的系统中的事件。\n[0028] 在一些实施方案中，记录器部件可进一步被适配成在产生记录文件时将所接收的记录消息转换成压缩二进制格式。记录器部件可以任意顺序来连续地接收从与一个或多个所提供的服务相关的一个或多个应用部件产生并且传输的记录消息。记录器部件可从所接收的记录消息产生压缩二进制数据块的列表，每个块包括上述数据字段(部件ID、消息ID、元数据和可能时戳)。记录器部件可将所接收的记录消息基于其时戳(如果可获得)按时间顺序来排序，或可(另外)通过其部件ID，相应地通过对应提供服务来对其进行排序。然后，记录器部件可将压缩二进制数据块逐个或逐块地写入一个或多个记录文件中，例如以列表形式写入。在进行此举时，记录器部件还可管理记录文件并且可经由上述预先分选来保持每个应用部件或每个提供服务的单独记录文件。通过保持每个服务的单独记录文件，例如用于免提电话的专用记录文件，稍后的自动或手动诊断可更容易地访问并且分析相关记录文件。\n[0029] 为了允许稍后分析所产生的记录文件，根据一些实施方案的系统可进一步包括：\n[0030] 用于存储所产生的记录文件的存储器；以及\n[0031] 报告器部件，其实施于处理单元中并且被适配成从存储器中读取以前存储的记录文件并且将其传输至实施于处理单元中的分析器部件。\n[0032] 存储器可为任何种类的存储器，但是具体来说，可通过永久性存储装置来实现，例如硬盘驱动器或光存储装置。圆形数据结构(环形缓冲器)可用于存储记录数据。所记录的数据量可受限于预定时段，然而，所述数据量可为可根据远程信息处理系统的处理和存储能力来配置的。在应用于汽车远程信息处理系统的特定情况下，此周期可等于过去几周的功率循环。更大记录周期可通过定期地或根据需要将圆形数据缓冲器转移至用于分析的后端(供应商)服务器来获得，由此平衡具有更高存储和处理能力的计算机的灵活性(参见下文)。后端服务器可为要求保护(汽车)系统的一部分。\n[0033] 报告器部件可实施于与记录器部件相同的处理单元中或不同处理单元中。在记录文件的记录期间，系统的报告器部件提供将所记录的二进制记录文件作为问题报告加以压缩的可能性。这些问题报告可含有例如基于车辆识别号码(VIN)以及问题报告的类型而由记录器记录并且由报告器部件选择的记录文件。然而，报告器部件还可仅将由未压缩的记录文件组成的问题报告传输至分析器部件。问题报告的产生和/或传输可手动地(例如由用户或诊断专家)或自动地(由车载的应用或从后端侧)来触发。具体来说，触发可从远程后端(供应商)服务器(具体来说，从分析器部件)经由现有网络和远程信息处理系统的相应部件发送至报告器部件。取决于触发的类型，附加信息可由报告器部件来添加至问题报告(例如，所连接的移动装置的列表、IP通道诊断等)。通常，所接收的问题报告的远程分析需要唯一地识别车载远程信息处理系统及其相关的报告，以使得来自特定车载系统的报告可出于长期存储目的而在接收器后端服务器处唯一地区别并且分选，但是本发明不限于此。\n[0034] 通常，分析器部件实施于外部处理单元中，例如作为后端服务器的一部分，即在车辆外部。然而，分析(具体来说，分析的缩减型式)还可由作为远程信息处理系统的车载部分的一部分的内部处理单元来执行(参见下文)。在这种情况下，分析器部件可实施于内部处理单元中，例如，实施有报告器部件的相同处理单元中。外部处理单元可为后端(供应商)服务器的一部分，其经由无线通讯或转移USB存储装置来与远程信息处理系统互动。服务器可进一步为便携式电子装置，如膝上型计算机、平板计算机或类似装置的一部分。服务器可呈独立系统形式或可以分散式网络来提供，例如，在注册汽车经销商处具有所连接的服务器。\n具体来说，服务器不受汽车远程信息处理系统的固有限制因素所限制，如空间、成本、冗余性、可靠性、存储和计算能力等。因此，远程信息处理系统的报告器部件将记录文件传输至外部分析器部件允许详细得多并且更快地分析和诊断远程信息处理系统的潜在发生问题。\n[0035] 在一个或多个实施方案中，分析器部件可实施于外部处理单元中，具体来说，包括于进一步包括非车载存储器的供应商服务器中，或可为车载分析器部件。\n[0036] 车载分析器部件可实施于车载处理单元中，具体来说，实施有报告器部件的相同处理单元中。在后一种情况中，记录文件从报告器部件至分析器部件的传输可在存储器中执行，具体来说，在处理单元的易失性存储器中执行。(外部)供应商服务器可包括非车载存储器，具体来说，呈硬盘驱动器或光存储装置形式。\n[0037] 一个或多个实施方案，报告器部件可被配置成接收来自供应商服务器的用于车载分析的触发信号和/或字典解码数据。具体来说，触发可如上所述从远程后端(供应商)服务器发送至报告器部件。字典解码数据可由车载分析器部件用于将记录消息从二进制格式转换成人可读文本(参见下文)。\n[0038] 在一个或多个实施方案中，报告器部件可进一步被适配成通过远程信息处理系统的无线通讯模块将以前存储的记录文件传输至分析器部件。无线通讯模块可为具有相应短距离天线的无线路由器、与局域网(LAN)或移动通讯网络进行通讯的调制解调器、具有相应天线的蓝牙收发器、固定安装于车辆中或作为移动终端连接至车辆的移动电信装置，或本领域的任何其它已知通讯模块。远程信息处理系统的无线通讯模块与包括分析器部件的远程系统的无线通讯模块之间的连接可直接建立，例如通过建立局域网中的服务器-客户端连接，或经由例如电信网络的现有网络。\n[0039] 已压缩的问题报告或记录文件可由报告器部件发送至消息传送部件，其提供用于下载和上传数据至后端基础设施的机构。具体来说，此消息传送部件可为车辆系统上的已有远程信息处理基础设施的一部分。通过使用此消息传送部件，报告器部件可基于车辆配置管理部件的配置将问题报告/记录文件传输至后端(供应商)服务器。车辆配置管理部件还可为当前远程信息处理基础设施的一部分，并且可提供关于往哪里传输问题报告和遵循哪些重试策略的信息。如果在任何重试之后传输问题报告仍为不成功的，报告或相应记录文件可永久存储在车辆上的远程信息处理系统的永久性存储装置中，并且一旦轮廓条件指示潜在成功环境就可再次尝试传输。在此方面，报告器部件可自动检测车辆上和车辆外部可利用的通讯基础设施并且扫描潜在成功的数据传输环境。\n[0040] 不同于在本领域中已知的其它方法，不需要特殊设备来记录并且读取记录数据。\n记录文件可在车辆内部和外部的现有通讯基础设施上转移，并且在不需要客户将他的车辆送至服务供应商的情况下加以分析。由于压缩的记录文件立即或及时传输至后端服务器，传输的问题报告变得可用于分析并且可提前预期客户投诉。问题报告的传输可在可利用的与车辆相关的任何内建或客户通讯基础设施上进行，并且在所采用通迅协议的所提供构件上的传送可为安全的。\n[0041] 在一个或多个实施方案中，报告器部件可进一步被适配成在预定时间，优选地2-3天之后将以前存储的记录文件传输至分析器部件，并且分析器部件被配置成存储所传输的记录文件。预定时间可通过与车辆的远程信息处理系统直接互动或远程地经由后端服务器来由用户(重新)配置。将报告器部件配置成以定期时间间隔来传输自前一次传输以来所积累的记录文件允许在后端侧积累与远程信息处理系统的连续性能相关的数据。此类数据可在与校正系统中的误差的需求无关的情况下来传输并且积累，并且用来评估远程信息处理系统、其部件和/或由远程信息处理系统提供的服务的总体质量。作为替代实施方案，报告器部件可被配置成每当存储器即将溢出时传输存储在车载存储器或存储装置(例如环形缓冲器)中的记录文件。通过这类配置，可避免记录数据的可能损失。报告器部件可进一步被配置成删除已经从车载存储器传输的记录文件。报告器部件还可被配置成只传输含有如下记录消息的那些记录文件，即报告预定类型(例如，关键或非关键)或与具体远程信息处理部件或服务相关的问题或误差的记录消息。\n[0042] 分析器部件可被配置成将传输的记录文件存储在存储器中，具体来说，是在非车载分析器部件的情况下存储在外部存储器中，即在车辆外部。通常，这类外部存储器可为后端服务器系统的一部分，所述系统包括实施分析器部件的外部处理单元。存储器可为在本领域中已知的任何存储装置，但是通常为永久性存储装置，如硬盘驱动器或光存储器。取决于用户确定的配置，分析器部件可系统地收集来自一个或多个车辆的记录文件，按照检测到的车辆ID、检测到的问题报告类型、检测到的所提供的服务类型等对上述记录文件进行预分选，并且存储在数据库中供将来分析。这类分析可例如基于检测到的问题的相关性来自动触发，或由用户(例如，机械工)来触发。可自动分析检测到的与例如车辆和驾驶员安全相关的问题，而车辆的信息娱乐服务系统的检测到的问题可延期直到可为所述问题分配专家为止。分析器部件还可被配置成收集特定应用部件的记录文件，例如偶尔出故障的移动电信装置的记录文件，以便能够执行统计分析。\n[0043] 对于所描述的系统，如果只记录最近时间的车载活动，例如2-3天的活动，可采用相对于处理单元和车载存储器的较小并且有效的部件。然而，也可产生特别非车载记录存储器，以使得可基于后端基础设施上的输出诊断记录的使用来扩展车载存储器。\n[0044] 在一个或多个实施方案中，分析器部件可进一步被适配成通过基于至少一个预定义使用案例自动分析传输的记录文件来执行自动故障根本原因分析。故障根本原因分析通常尝试识别问题的一个或多个根本原因而非尝试校正问题的即时症状。举例来说，从网络下载失败的根本原因可能是因为网络连不上或因为应提供用于下载数据的远程服务器出故障而使远程信息处理系统未能连接至特定网络，而下载停滞这个症状相对于根本原因可为非决定性的。本发明系统和方法允许识别远程信息处理系统中的所发生问题的一个或多个实际根本原因，方法是提供来自所有相关涉及部件，不论是应用部件还是远程信息处理部件，理想情况下来自提供特定服务的相应链接的所有部件的记录信息，其中包括于每个记录消息中的部件ID和信号ID允许将每个记录消息唯一地分配至部件和发生的事件。通过分析所传输的记录文件和其包括的记录消息，分析器部件可最终确定所诊断问题的故障根本原因并且将有价值的信息提供给专家，所述专家然后可使用此信息来校正远程信息处理系统。故障根本原因分析可遵循本领域的根本原因分析的任何熟知规则，但是具体来说，可为基于故障的根本原因分析。\n[0045] 由于根据本发明的记录消息基于特定系统内的特定事件和使用案例来产生，因此在记录文件中产生所发生误差之间的明显依赖性。因此，与在本领域中已知的DTC的依赖性过滤相比，根据本发明的记录文件允许更具描述性和精确性的方法。知道可能事件和使用案例允许通过解析由本发明系统产生的记录文件来自动分析系统误差和误差的依赖性。\n[0046] 分析器部件可通过基于至少一个预定义使用案例而自动分析所传输的记录文件来执行自动故障根本原因分析。通常使用案例为步骤列表，所述步骤列表通常定义角色(在本文中为用户或应用部件提供服务)与系统(在本文中为汽车远程信息处理系统)之间的互动，以便实现目标，在本文中为提供远程信息处理系统的服务。使用案例可由专家来预先定义，具体来说，特定远程信息处理部件的制造商或特定应用部件的供应商。由于不同事件通常产生新的使用案例，因此每个服务和其相应应用部件可具有多个使用案例，正如同每个应用部件和/或远程信息处理部件可具有多个状态并且因而产生多个不同记录消息。因此，分析器部件可通常处置很多预定义使用案例，所述预定义使用案例可存储在外部存储器中，即在车辆外部，或在车载分析器部件的情况下存储在车载存储器中，例如呈数据库形式。然而，预定义使用案例的列表相对于涵盖在通过应用部件来提供特定服务时可能发生的所有可能事件来说不一定是完整的。如果分析器部件未能识别匹配使用案例(进一步参见下文)，相应故障信息可由分析器部件来产生，并且匹配使用案例可由专家来定义并且基于分析器部件的分析报告来添加至预定义使用案例的列表。根据本发明系统，可预先定义使用案例，其以有意义的方式，即基于实际基于事件的情况来建立消息ID与记录消息的元数据之间的关系。\n[0047] 在一个或多个实施方案中，分析器部件可进一步被适配成通过以下步骤来分析所传输的记录文件：\n[0048] 从存储器中读取多个预定义使用案例；\n[0049] 从所传输的记录文件中提取至少一个记录消息；以及\n[0050] 通过将至少一个所提取的记录消息与至少一个预定义使用案例的至少一个状态匹配来从多个预定义使用案例中识别至少一个预定义使用案例；\n[0051] 其中至少一个预定义使用案例定义为状态流程图中呈现的多个状态和关系。\n[0052] 可定义多个预定义使用案例中的使用案例并且稍后借助于图形程序来表示，然后翻译成可解析的格式，如XML。每个使用案例定义为包括“开始”(START)、“事件”(EVENT)和“结束”(END)状态的状态流程图。每个状态代表一个记录信号(1:1分配)，其中记录信号包括至少一个部件ID和消息/信号ID。每个状态可进一步包括至少一个状态参数，其可根据记录消息的元数据中所含有的至少一个参数来设定或与其匹配。“开始”状态是属于使用案例的第一记录信号，并且因而触发使用案例的开始(入口点)。“结束”状态标记使用案例的结束(出口点)。使用案例可具有多个入口和多个出口点。在“开始”与“结束”状态之间，可采用任意数量的中间状态(“事件”状态)。状态通过定向边缘来连接以便指示关系方面的状态顺序。因此，使用案例可描述为可含有环的定向图。使用案例定义为状态流程图的更详细说明在下文进一步给出。使用图形程序来定义和/或代表使用案例使配置并且使用由分析器部件所提供并且基于本发明系统的自动分析系统的过程极大地简化。使用案例可仅通过从预定义状态的集合中选择状态并且将所述状态加以连接来定义。故障根本原因分析的结果可借助于相应使用案例以状态流程图形式的图形表示来在视觉上呈现和可容易地由专家来诊断。\n[0053] 如前述，存储器可为任何永久性存储器，例如，硬盘驱动器或光存储装置。在非车载分析器部件的情况下，实施分析器部件的处理单元和存储器可为后端(供应商)服务器的一部分。分析器部件从存储器中读取多个预定义使用案例，其中根据分析所传输的记录文件的初步结果，每次可针对一个状态来执行使用案例之读取。举例来说，分析器部件可根据所分析的记录文件中的第一记录消息的部件ID来读取与远程信息处理系统的应用/远程信息处理部件相关的所有预定义使用案例的“开始”状态(进一步参见下文)。然后通过分析记录文件中的进一步记录消息，分析器部件可在第一步骤中选择的使用案例群组之间进行选择，所述使用案例与进一步记录消息中含有的部件ID、信号ID和/或元数据相容，并且由此最终从多个预定义使用案例中识别至少一个预定义使用案例，方法是连续地将从所传输的记录文件中提取的记录消息与预定义使用案例的连续状态匹配，并且因而将最初群组的候选预定义使用案例变窄至至少一个预定义使用案例。如上所述，至少一个预定义使用案例的识别失败可由分析器部件来报告。代替依序读取预定义使用案例，分析器部件还可全部读取使用案例，然后在分析所传输的记录文件的同时逐步地对其进行处理。\n[0054] 为了分析所传输的记录文件，分析器部件通常逐个从所传输的记录文件中提取记录消息。然而，分析器还可同时提取记录文件中含有的所有记录消息，然后继续对其进行分析。作为提取的一部分，分析器部件可将已经由远程信息处理系统的记录器部件压缩的二进制数据解压缩。分析器还可执行故障根本原因分析，方法是从记录文件中提取所有记录消息并且将每个所提取的记录消息分配至引用记录消息数据的所有那些使用案例，并且由此在执行详细分析之前选择一组相关使用案例，方法是依序单步调试来自所选择组的使用案例并且将所提取的记录消息与使用案例的状态匹配。\n[0055] 除了以上描述的将一个记录信号1:1分配至使用案例定义中的一个状态以外，记录消息可按照其元数据来区分并且取决于元数据中含有的至少一个参数的值来分配多个不同状态。元数据中含有的参数可由分析器部件基于表1中定义的标准来评估。如果所有参数匹配关于使用案例状态提供的定义，那么记录消息视为是使用案例的一部分。\n[0056] 标准                 含义\n[0057] *                    参数值不相关\n[0058] x                    参数必须精确地具有所提供的值x\n[0059] [x,y]                参数必须在所提供的数值范围[x,y]内\n[0060] $VARIABLE_NAME       参数必须等于变量\n[0061]                      $VARIABLE_NAME的内容\n[0062] 表1：基于参数值的消息分配的标准\n[0063] 此处，值x和y以及VARIABLE_NAME为使用案例的定义的一部分。\n[0064] “事件”状态群组可重组为子使用案例。以此方式，可实现使用案例分解成逻辑块或任务。这允许涉及多个部件的使用案例的更好建模。这也允许重新使用来自多个主要使用案例或中间子使用案例(可能涉及多级别的子使用案例嵌套)的共同状态流模式。\n[0065] 在本发明系统的一个或多个实施方案中，远程信息处理系统的至少一个处理单元可包括能够同时执行至少一个应用部件的并发实例（concurrent instance）的多线程系统，至少一个预定义使用案例的至少一个状态可包括至少一个使用案例变量，并且分析器部件可进一步被适配成识别所识别的预定义使用案例的实例，方法是将至少一个记录消息的元数据中所包括的至少一个参数与至少一个使用案例变量匹配。此处，多线程系统表示能够同时执行至少一个应用部件的多个实例的任何系统，例如多核心处理单元、超线程处理单元或任何有多任务能力的处理单元。在此类情况下，可同时产生或排定至少一个应用部件的多个并发实例。至少一个应用部件的并发实例可在相同处理单元或不同处理单元上执行。然而，并发实例可代表对不同参数数据执行相同程序码。举例来说，下载客户端可运行多次以便下载不同文件或访问不同网络。根据本发明，可经由使用记录消息的元数据中的参数而将此参数数据包括于记录消息中。\n[0066] 明确地允许或不允许在远程信息处理系统中运行应用部件的多个并发实例可为有用的，因为同一使用案例的记录消息的多次出现可指示正常或有问题的系统行为。举例来说，每次只应允许单个语音电话连接，而多个并发数据连接将为完全有效的。为了指示使用案例可同时多次运行，可设定每个使用案例的相应限定符。此外，为了正确地追踪并行运行的使用案例，可使用根据本发明的新的变量追踪特征，其在下文更详细地描述。\n[0067] 在多实例使用案例的情况下，具体难题是确定具体记录消息与使用案例的哪个实例相关。取决于起始时间和其它系统参数，应用部件的两个并发实例通常以不可预测的交错方式将记录消息传输至记录器部件。因此，由记录器部件产生的记录文件可含有一系列记录消息，所述记录消息属于第一实例或第二实例但是不遵循特定顺序。当处理多个并发实例时，通常可获得多个可能匹配的记录信号，但是仅消息参数可决定信号属于哪个具体使用案例实例。举例来说，多个下载队列可为活动的，其发出下载过程的相同起始信号，但是在单个参数(例如队列识别符)方面不同。另一个实施例是如下子使用案例，其使用例如下载ID的参数作为识别符来追踪属于它的消息，其进而被一个或多个母体使用案例引用。\n[0068] 此难题在本发明的当前实施方案中予以解决，方法是使用可保持消息元数据值的使用案例变量。使用案例定义可经由如$VARIABLE_NAME=的语句来声明变量。然后，“开始”、“事件”或“结束”状态可基于记录消息的元数据中所包括的至少一个参数或基于使用案例分析期间的另一变量经由赋值语句来将值分配给这些变量，所述参数已经匹配至对应状态。变量可从一个状态传递至下一个状态。然后，基于所定义的变量与记录消息的元数据的至少一个参数的比较，分析器部件可使用所定义的变量作为标准将记录消息分配至预定义使用案例的实例。保留的变量可通过名称$RETURN来引入。所述变量可用于在结束子使用案例后分配子使用案例内部的元数据内容以供调用程序(即母体使用案例)进一步处理，这类似于C函数的返回参数。包括子使用案例的多实例使用案例追踪的实施例进一步在下文给出。\n[0069] 在各种实施方案中，多个并发使用案例实例的准确分离可经由追踪含于记录消息元数据中的ID而可行。作为一个非限制性实施例，如果同时下载多个文件，然后有可能正确追踪哪个具体文件下载导致问题。这包括追踪哪个子使用案例(如，开启数据连接、请求服务级别协定管理员的净访问许可等)属于下载使用案例实例的可能性。\n[0070] 分析器部件可进一步被适配成自动产生每个所分析的记录文件的总结报告。报告可提供记录事件的时窗，以及系统功率循环的数量。报告可进一步含有从记录文件识别的所有使用案例的概述表。每个使用案例的结束状态可与指示成功、误差或报警状态的状态标志一起报告。基于特定使用案例的总结报告，专家可决定确定相应服务的成功率并且采取进一步措施，例如召回车辆以供检修或开始有问题的应用部件和/或远程信息处理部件的更详细记录(参见下文)。\n[0071] 具体来说，含有对应于所分析的记录文件的所有使用案例的自动产生的总结文件允许迅速评估记录文件。通常，如果仅很少的使用案例执行失败，那么专家容易发现这些案例，包括精确结束状态或最后一个执行消息。此外，失败使用案例的完整跟踪可在与可同时发生但是不属于具体使用案例的其它消息分离的情况下直接用于进一步分析。这提供优于常规跟踪分析的显著优势，其中跟踪然后必须针对有问题的使用案例来手动地加以过滤。\n这也提供优于标记DTC的显著优势，其中关于哪个系列的系统条件导致决定产生所记录的故障码，很少附加信息或没有附加信息可供利用。\n[0072] 总结报告提供快速收集关于相对于所提供的服务的报警和误差的积累信息的可能性，包括发生计数。由于记录文件所含有的可能不仅仅是误差，即实际上执行的所有使用案例(在所记录的时间框架期间)，因此总结报告可用于收集关于用户行为、优选使用案例、使用案例成功率等的更详细信息。\n[0073] 在替代实施方案中，分析器部件可实施于车辆上，并且报告器部件可经由车辆的现有基础设施(例如，导线、蓝牙天线、无线天线等)来将记录文件传输至分析器部件。具体来说，分析器部件可实施于与报告器部件相同的处理单元中，并且将记录文件传输至分析器部件可在处理部件的存储器(例如RAM)内部发生。车载分析器部件可被配置成根据以上描述的本发明系统和方法来完成记录文件的轻量级分析。除了这类轻量级分析以外，记录文件还可传输至实施完整版本的分析器部件的外部处理单元，所述完整版本的分析器部件可被配置成根据以上描述的本发明系统和方法来执行完全分析。轻量级报告可通过采用合适输出装置(如，在图形显示器上显示的浏览程序或文本编辑程序)来变得可直接在车上利用。\n[0074] 包括车载分析器部件和远程分析器部件的远程信息处理系统可基于远程分析和车载轻量级分析的组合来向用户(例如，驾驶员)提供关于如何修理系统中出现的问题的建议。当用户或车载分析器部件注意到所监测(记录)的服务出现问题时，用户(驾驶员)或保修人员(不需要位于经销商站处)可通过传输相应记录文件来请求后端(供应商)服务器进行分析。关于问题类型的基本信息可作为问题报告的一部分包括于请求中。后端服务器的远程分析器部件可如上所述来执行记录文件的完全分析并且准备受影响车辆的解码数据。\n远程分析器部件可进一步将传送此解码数据的触发信号发送至车辆，具体来说发送至车载报告器部件。准备解码数据可涉及例如机械工的专家，但是还可基于自动完全分析过程，即分析总结。\n[0075] 可在车辆中通过SMS、IP或其它在线连接来接收触发。响应于此触发，报告器部件可从后端服务器撷取解码数据。为此目的，车辆可例如通过VIN、误差发生时间等来识别。解码数据可已经包括关于如何修理已知问题的信息。\n[0076] 在接收解码数据时，所传输的记录文件中所包括的本地记录数据可经受车载分析器部件的轻量级分析并且以人可读的问题报告形式，例如，以车辆浏览程序中的网页形式直接呈现给车辆中的用户(或保修人员)。然后，用户可开始基于轻量级分析和所接收的解码数据来校正问题。或者，车载分析器部件可尝试自动修理问题，例如，通过安装与所接收的解码数据一起提供的软件补丁。\n[0077] 在一个或多个实施方案中，至少一个应用部件可进一步被适配成在从记录器部件接收预定义触发信号后将其状态传输至记录器部件。通常，应用部件或远程信息处理部件的状态的确定和传输可由部件本身来触发，例如基于部件的特定配置在检测到特定事件如部件故障后，或由记录器部件来触发。通过记录器部件的触发可为直接的，例如请求传输部件的当前状态(例如，空闲)，或间接经由操纵相应部件的配置。因此，举例来说，记录器部件可改变部件传输状态的时间间隔，或部件传输状态之后的时段。记录器部件还可启动从通常不传输状态的部件的状态传输。状态的附加传输可限于用户已经经历相应服务的问题的具体时段，例如每天的特定时间。将要发送哪些触发可由记录器部件基于从后端服务器接收并且由报告器部件处理的触发配置数据来确定。由此，专家可能能够重新配置记录系统以便针对特定服务和/或在特定时间间隔期间来提供更详细记录报告。通过使得记录系统能够基于从后端服务器接收的配置数据来适配其详细程度，标准(即没有额外细节)记录文件和问题报告可保持微小，这样使得存储记录文件的车载存储器可保持较小并且能量有效。另外，应用部件可在检测到预定义误差后触发更详细记录过程。\n[0078] 在一个或多个实施方案中，分析器部件可进一步被适配成通过应用预定义多级别字典来将所提取的至少一个记录消息转换成人可读的文本。两个级别的描述方案可用作预定义多级别字典以便将二进制记录消息翻译成人可读文本。最高级别的文件可定义全局消息过滤器并且输入较低级别、特定于部件的定义文件。输入特定于部件的文件具有能够根据在提供特定服务过程中是否牵涉到相应部件来单独地维护部件翻译文件的优势。翻译可使用部分集的翻译(定义)文件来进行，以便通过省略已知与分析特定问题不相关的数据的处理来加速翻译过程。此外，消息过滤器可用于将所记录的信号根据其含义来分类(例如，信息、报警或致命误差消息)。实施多级别字典的特定实施例进一步在下文给出。以上描述的方法考虑到模块化的应用，其中翻译文件按照部件并且可独立地来维护。最高级别的描述文件可用于避免共存的部件之间的任何冲突。\n[0079] 在各种实施方案中，记录远程信息处理系统的方法可包括：\n[0080] 将至少一个应用部件的至少一个状态以记录消息的形式传输至记录器部件，所述应用部件提供远程信息处理部件的服务并且实施于处理单元中；\n[0081] 由记录器部件来接收记录消息；以及\n[0082] 基于所接收的记录消息来产生记录文件。\n[0083] 记录文件由记录器部件基于所接收的记录消息来产生。相对于记录、分析和/或诊断系统行为的如上所述的远程信息处理系统的相同变化和/或延伸也可适用于记录远程信息处理系统的方法。记录可特别地、连续地或定期地执行。\n[0084] 具体来说，如上所述，记录消息可包括：\n[0085] 至少一个应用部件的部件识别符；\n[0086] 描述至少一个应用部件的所传输的至少一个状态的消息识别符；以及\n[0087] 包括至少一个参数的元数据；\n[0088] 并且其中记录消息具体来说包括时戳。\n[0089] 所引用的标识符和元数据可根据以上描述的变化和规则由本发明方法来规定并且采用。\n[0090] 在一个或多个实施方案中，本发明方法可进一步包括：\n[0091] 将所产生的记录文件存储在存储器中；\n[0092] 从存储器中读取以前存储的记录文件并且将所述记录文件传输至实施于处理单元中的分析器部件；以及\n[0093] 通过基于至少一个预定义使用案例自动分析所传输的记录文件来执行自动故障根本原因分析。\n[0094] 如上所述，分析器部件可实施于外部处理单元中，具体来说作为后端(供应商)服务器的一部分或轻量级分析器部件可替代地或另外实施于车载处理单元中。另外，可应用如上所述的传输记录文件并且执行自动故障根本原因分析的相同变化和延伸。\n[0095] 在一个或多个实施方案中，本发明方法可进一步包括：\n[0096] 从存储器中读取多个预定义使用案例；\n[0097] 从所传输的记录文件中提取至少一个记录消息；\n[0098] 通过将至少一个所提取的记录消息与至少一个预定义使用案例的至少一个状态匹配来从多个预定义使用案例中识别至少一个预定义使用案例；\n[0099] 其中至少一个预定义使用案例定义为在状态流程图中呈现的多个状态和关系；\n[0100] 获得关于所识别的至少一个预定义使用案例的分析数据；以及\n[0101] 将分析数据以人可读的格式来显示。\n[0102] 可应用如上文相对于使用案例定义以及将记录消息与使用案例匹配所述的等效改进和延伸。另外，根据任何以上描述的变化，通过将包括于至少一个所提取的记录消息的元数据中的至少一个参数匹配来对所识别的预定义使用案例的实例进行识别可包括于本发明方法中。具体来说，所获得的分析数据可包括指示所发生问题的至少一个记录消息，所述消息例如来自已经报告误差的应用/远程信息处理部件。人可读的格式可通过如上文所述来应用多级别字典而从分析数据产生。所述格式可进一步基于对应于所识别的至少一个预定义使用案例的状态流程图的图形表示来产生。\n[0103] 所描述的本发明设备和方法允许轻量级并且仍然富含特征的记录并且提供合适工具以用于统计分析非关键字段误差的使用以及早期检测，以及关于可能导致客户投诉的个别误差的初步信息。因此，从长远看来，本发明可有助于改进客户体验。\n附图说明\n[0104] 相对于附图来详细地解释其它特征和示例性实施方案以及本发明的优势。应了解本发明不应理解为受限于以下实施方案的描述。此外，应了解下文描述的一些或所有特征还可以替代方式来组合。\n[0105] 图1展示汽车远程信息处理系统的示例性实施方案。\n[0106] 图2展示由汽车远程信息处理系统中的应用部件提供的服务的示例性列表。\n[0107] 图3展示示例性诊断系统架构。\n[0108] 图4展示使用案例的状态流程图的实施例。\n[0109] 图5展示涉及子使用案例的使用案例的状态流程图。\n[0110] 图6展示使用变量的状态流追踪的实施例。\n[0111] 图7展示用于文件下载的预定义使用案例的表现，其包括用于网络资源预留和释放的子使用案例。\n具体实施方式\n[0112] 下文相对于图1来例示汽车远程信息处理系统的可能实施方案。应了解，所描述部件仅仅意图作为汽车远程信息处理部件的非限制性实施例，其中一些部件可省略或替换为本领域中已知的其它远程信息处理部件。\n[0113] 部件100至145和170至182安装于车辆中，而部件150至161为外部部件，这些外部部件并非汽车远程信息处理系统的一部分，但是可与车辆的一些远程信息处理部件互动。\n[0114] 装备有远程信息处理系统的车辆可含有显示器104，作为位于车辆中的视觉前端接口。用户可能还能够经由触敏屏幕、经由按下按钮、经由可听的语音和语音合成或本领域中已知的其它HMI(人机互动)部件来与接口互动。经由可听的语音和语音合成或分析的互动可经由用于接收来自用户的输入的麦克风131和A/D转换器130并且经由用于向用户给出输出的D/A转换器120、放大器121和一个或多个扬声器122。视觉前端接口可为用于用户与远程信息处理系统集中式互动的机头单元的一部分或独立于一个或多个专用机头单元\n105，例如，用于用户与远程信息处理系统的音频或电话部件互动的专用机头单元。\n[0115] 在图1中展示的说明性实施方案中，中央处理单元100(通常CPU或GPU或嵌入系统)控制远程信息处理系统的操作的至少一部分。然而，本发明不限于此，而是可提供分配给具体远程信息处理部件或远程信息处理部件群组的至少一个另外处理单元，如例如与视频显示器142一起提供的CPU141，所述视频显示器可能是从存储装置(如硬盘驱动器140)显示电影的后座娱乐系统的一部分。处理单元允许车载处理指令、命令和例行程序，尤其作为远程信息处理系统的应用部件的一部分。处理单元100可进一步连接至非永久性和永久性存储装置140。在此说明性实施方案中，非永久性存储装置为随机存取存储器(RAM)并且永久性存储装置为硬盘驱动器(HDD)或闪速存储器。\n[0116] 处理单元100还可具备许多不同输入，从而允许用户面与处理单元互动。在此说明性实施方案中，提供了全部麦克风131、辅助输入132、USB输入123、GPS输入133和蓝牙输入\n102。可提供输入选择器以便允许用户在不同输入之间切换。麦克风131的输入在传递至处理单元之前通过A/D转换器130来进行模数转换。\n[0117] 来自远程信息处理系统的输出可包括但不限于视频显示器124和扬声器122或立体/环绕系统输出。扬声器可连接至放大器121并且可经由数模转换器120来接收来自处理单元100的信号。还可经由具有蓝牙天线103的蓝牙收发器102输出至远程蓝牙装置，如具有蓝牙天线172的个人导航装置170。与个人导航装置的通讯也可经由USB连接器123和171来实现。远程信息处理系统可进一步包括车辆导航装置134，其可经由基站150和多频带天线\n110或移动终端111与GPS单元133和/或移动网络160互动。移动终端111可尤其为移动电话、智能手机、PDA等，并且可直接经由USB连接器123或经由具有天线103的蓝牙收发器102连接至处理单元100。多频带天线110可经由有线或以无线方式经由调制解调器101来与处理单元100交换数据。在本文中，基站150和网络160并非远程信息处理系统的一部分而是提供于车辆外部。在一些实施方案中，基站150可为WiFi访问点。\n[0118] 数据可利用例如数据计划、语音上数据或与移动终端相关的DTMF信号音在中央处理单元100与网络160之间通讯。多频带天线110和移动终端111可与基站或WiFi访问点150双向交换数据。调制解调器101也可经由与蜂窝塔150通讯而直接与网络160通讯。作为非限制性实施例，调制解调器101可为USB蜂窝调制解调器并且通讯可为蜂窝通讯。\n[0119] 在一个说明性实施方案中，处理单元100具备操作系统，所述操作系统包括API以用于与调制解调器应用软件通讯。调制解调器应用软件可访问蓝牙收发器102上的嵌入模块或固件，以便完成与远程蓝牙收发器(例如移动终端111的收发器)的无线通讯。在另一个实施方案中，移动终端111可包括用于语音频带或宽频带数据通讯的调制解调器。如果用户具有与移动终端111相关的数据计划，数据计划可允许宽频带传输并且远程信息处理系统可使用宽得多的带宽(加速数据传送)。在另一个实施方案中，移动终端111可替换为安装于车辆中的蜂窝通讯装置(例如，并且不限于调制解调器101)。在另一个实施方案中，移动终端111可替换为能够例如在802.11g网络(即，WiFi)或WiMax网络上通讯的无线局域网(LAN)装置。在一个实施方案中，传入数据可经由语音上数据或数据计划来穿过移动终端111、通过车载蓝牙收发器102并且进入中央处理单元100。\n[0120] 不论传入数据或传出数据或临时数据，都可存储在HDD140上或RAM140或任何其它存储媒体中直到不再需要数据时间为止。HDD140或其它存储媒体可尤其用作存储器，以用于存储所产生的记录文件直到报告器部件将所述记录文件传输至外部分析器部件为止。此传送至外部分析器部件可经由调制解调器101、多频带天线110、蓝牙收发器102或移动终端\n111来执行，例如传送至移动网络160或无线网络。\n[0121] 中央处理单元可进一步与各种其它辅助装置180通讯。这些装置可经由无线182或有线181连接(例如USB连接)来连接。另外或替代地，CPU100可使用例如WiFi收发器107来连接至基于车辆的无线路由器106。这可使得CPU在本地路由器106的范围中连接至远程网络。\n[0122] 处理单元100可进一步与收音机、CD播放机或DVD播放机143互动，以便向立体音响系统122和/或视频显示器142提供音频和/或视频。音频和/或视频还可经由多频带天线110或移动终端111从移动网络160、无线网络或数字广播网161(数字音频广播，数字视频广播)经由车辆外部的广播发射机151来提供。音频和视频数据可经由以上描述的连接来下载或串流。在下载的情况下，数据可临时或永久存储在HDD140或其它存储装置中。另一处理单元\n141可稍后从HDD140读取所存储的数据并且经由车辆的扬声器系统122或视频显示器142来提供视频和/或音频服务。\n[0123] 处理单元100可进一步与麦克风131和车辆的扬声器系统122互动，以便例如经由移动终端111来提供免提电话。类似地，处理单元100可与移动终端111和车辆诊断(未展示)互动以便发送紧急呼叫或故障呼叫(进一步参见下文)。\n[0124] 处理单元100还可与引擎控制单元(ECU)144互动以便控制引擎参数或监测车辆引擎。类似地，处理单元100可与动力总成控制模块(PCM)144和一系列传感器系统145(如例如但是不限于胎压监测系统、道路条件传感器、停车传感器、温度传感器、环境光传感器等)互动。汽车远程信息处理系统内的有线通讯可使用MOST(媒体导向系统传输)、CAN(控制器区域网络)、IEEE1394或在本领域中已知的其它技术来执行。虽然处理单元与ECU或PCM的互动相对于EOBD(欧洲车载诊断)或OBD-II(车载诊断-II)条例至关重要，但是本发明着重于汽车远程信息处理系统中提供一组具体信息娱乐服务和/或车辆安全服务的那些部件，如下文描述。\n[0125] 图2展示作为说明性、而非限制性实施例的由汽车远程信息处理系统中的应用部件提供的服务的列表。在此图中，相应应用部件全部实施并且运行于一个控制单元200上。\n然而，应了解，如上文已讨论的，每个所列出的服务可由一个以上应用部件或应用部件的完整链接来提供，其中每个应用部件可与一个或多个汽车远程信息处理部件互动。所涉及的应用部件可实施于中央处理单元100或分配至具体远程信息处理部件的处理单元200中。具体来说，可提供车辆安全服务201-208和/或信息娱乐服务210-217的群组中的服务：\n[0126] 如果应用部件接收到来自车辆的合适传感器145的信号，例如报告预定强度的撞击，指示已经发生(严重)车辆事故，那么应用部件可例如经由移动终端111或调制解调器\n101和多频带天线110来发送与如欧洲委员会的标准定义的呼叫911类似的紧急呼叫201。所涉及的远程信息处理部件和处理单元100可安排独立于车辆的电池以外的备用电池系统，以便即使在事故期间车辆主要部件的完整性已经受损的情况下仍能够发送紧急呼叫。本发明远程信息处理系统和方法提供记录并且诊断在发送如上所述的这类紧急呼叫时可能发生的潜在问题的方法。对于给定服务，通过根据本发明的记录器部件来接收并且处理成记录文件的记录消息可包括可通过触发处理单元上的相应应用部件的执行来触发发送紧急呼叫的来自传感器的记录消息，或可限于与实际发送呼叫相关的记录消息，即从所涉及的远程信息处理部件如调制解调器101和多频带天线110传输的记录消息。\n[0127] 类似地，在例如经由来自ECU或PCM部件的相应信号检测到车辆故障后，应用部件可经由移动终端111或调制解调器101和多频带天线110将故障呼叫202发送至零售商、汽车销售店或汽车协会。最后，在检测到一个或多个车辆部件的非关键问题，例如外部反射镜加热器的故障后，应用部件可经由移动终端111或调制解调器101和多频带天线110将服务呼叫203发送至零售商或汽车销售店，以便通知机械工关于在定期检修计划以外的附加车辆检修的需要。根据所发生问题的紧急性，机械工可决定是否召回车辆以供检修或将问题的校正推迟至下一次定期检修。在收到不同触发信号后，紧急呼叫、故障呼叫和服务呼叫还可由同一应用部件来提供。\n[0128] 另一应用部件可例如通过与汽车的闭锁系统互动来提供安全服务206。在检测到车辆事故后，应用部件可例如开启以前锁定的车门，因为一些车辆行驶时通常锁定车门。另外，在所有乘客已经离开车辆之后，门可由应用部件自动锁定。\n[0129] 另一应用部件可提供车辆到车辆报警207和/或车辆到基础设施报警208。这类报警可包括关于道路或交通条件的报警，如道路冻结、交通阻塞、汽车事故等，并且可例如经由无线路由器106和其短程天线107或调制解调器101在车辆之间直接交换，或例如经由多频带天线110或移动终端111在车辆与相应基础设施之间交换。相应基础设施可为移动网络\n160的一部分和/或涉及数字广播网161。在与GPS单元133和/或车辆导航装置134互动的情况下可进一步提供服务。示例性链接可由以下应用部件组成，所述部件经由基站150和移动终端111来接收来自交通网络160的报警，经由无线路由器106和其天线107将报警转播至后面的车辆，接收来自GPS单元133的GPS信息，和请求车辆导航装置134建议到达目的地的替代路线。通过使用本发明系统，应用部件可将在任何所涉及的远程信息处理部件或应用部件(例如车辆导航装置的旅行推销员解算器)中发生的误差报告至记录器部件，以便存储和/或传输至外部分析器部件。\n[0130] 仅出于完整性，另一应用部件可提供车载诊断服务204，其诊断并且报告车辆的具体部件(包括远程信息处理部件)的硬件故障，例如刹车、灯等，从而可充当触发发送服务呼叫的基础。类似地，应用部件可经由引擎控制单元来监测并且诊断车辆的引擎205并且将问题报告至记录器部件以供立即或稍后分析。\n[0131] 本发明系统可进一步提供一系列信息娱乐服务，如下文描述。\n[0132] 应用部件可提供与麦克风131和A/D转换器130和车辆的立体音响系统以及移动终端111互动的免提电话210，所述立体音响系统包括扬声器122、放大器121和D/A转换器120。\n所提供的服务可涉及其它应用部件，如例如语音识别部件或控制收音机音量和/或显示器装置的应用部件。\n[0133] 另一应用部件可提供与GPS单元133、车辆导航装置134或个人导航装置170以及调制解调器101和多频带天线110互动的车载导航服务211。\n[0134] 其它应用部件可提供音频服务212，例如AM/FM收音机接收、带内同频(IBOC)收音机接收或数字音频广播收音机，和/或视频服务213，例如DVD/CD回放、HDD回放或数字视频广播服务。取决于服务，移动终端111或多频带天线110可接收来自基站150或广播发射机\n151的数据。存储在HDD140上的视频的回放还可涉及另一处理单元141和另一(后部)视频显示器142，其中另一处理单元141处置显示电影所需的大多数处理，而中央处理单元100上的应用部件只监测服务的成功，或另一处理单元141可甚至实施应用部件本身，这样使得来自应用部件的记录消息传输至可实施有记录器部件的中央处理单元。\n[0135] 作为其它服务，应用部件可例如在与调制解调器101和多频带天线110、无线路由器106或移动终端111互动的情况下提供网络访问214和/或电子邮件访问215。通过移动终端111和/或多频带天线110，另一应用可在与车辆导航装置134和GPS单元133互动的情况下接收来自网络160的交通信息216，并且建议不同路线。\n[0136] 最后，应用部件可提供依赖于HMI(人机互动)217的服务，如触敏屏幕、鼠标、操纵杆或轨迹球以便例如玩游戏，或浏览车辆的监测系统、与车辆导航装置134互动或操作车辆的媒体站。\n[0137] 在与一个或多个远程信息处理部件互动的情况下实施于处理单元中的应用部件可能提供几乎无限数量的服务，并且本发明不限于以上描述的实施例而是可应用于在本领域中已知的任何基于远程信息处理系统的服务。只要相应部件，不论应用部件还是远程信息处理部件，被适配成提供记录消息至控制应用部件，本发明系统和方法可应用于整个服务链接，所述控制应用部件将其状态以记录消息的形式传输至记录器部件。然而，即使控制应用部件仅被适配成以记录消息的形式来传输其状态，本发明仍然可以相对于可能故障根本原因的较低详细程度来执行。\n[0138] 图3展示记录和诊断系统架构的示例性实施方案。在这个实施方案中，应用部件、记录器部件、报告器部件和记录文件全部实施于安装在车辆中的一个计算机系统中。然而，每个部件还可独立地实施于安装在车辆中的不同计算机系统中。应用部件将其状态以记录消息的形式传输至记录器部件，所述记录器部件可将记录消息以有序和紧凑形式写入记录文件中。报告器部件可由任何应用部件和/或从车辆外部(例如由分析器部件)提示，以便读取记录文件并且将记录数据传递至后端分析器部件。此外，相同记录数据可通过其它数据传送机构在具有记录器部件和分析器部件的计算机系统之间传输，例如经由USB数据棒来传输。分析器部件可提供根据本发明来自动分析记录数据的机构。\n[0139] 下文给出记录消息的标准帧格式的可能实行方案的两个实施例。第一实行方案展现作为元数据且各自由4个字节组成的固定数量的参数。\n[0140] 时戳       部件ID      信号ID      参数1        参数2       参数3[0141] 4个字节    1个字节     1个字节     4个字节      4个字节     4个字节[0142] 表2：简单压缩二进制记录格式\n[0143] 第二实行方案展现可映射于任何消息特定数据结构(例如C++结构)的可变大小型参数元数据。\n[0144] 时戳       部件ID      信号ID     数据大小     数据容量\n[0145] 4个字节    1个字节     1个字节     1个字节      0至255个字节(变量)[0146] 表3：高级二进制记录格式\n[0147] 为了允许将来系统的调节扩展，将信号和部件ID限制于不采用值的整个范围可为适用的。举例来说，在参考实行方案中，保留部件和信号ID的值0xFF以供将来使用。\n[0148] 图4展示使用案例的状态流程图的实施例。使用案例的“开始”状态不能含有任何进入边缘以便唯一地界定使用案例入口点。出于简单起见，与状态相关的记录信号由字母A至H来指示。构成使用案例状态的记录消息可任意地分布于多个系统部件之间，即应用部件和远程信息处理部件。为了避免在可从许多其它状态(例如异常中断)达到的“结束”状态的情况下出现很多箭头，可界定没有进入入路径的“结束”状态。这些“结束”状态指示可由任何以前“开始”或“事件”状态来达到“结束”状态。\n[0149] 为了允许使用案例的快速定义，可提供含有使用案例的建造块的模板。模板可含有不同的可利用状态、状态参数、部件和部件ID定义标签和总体描述字段模板。\n[0150] 图5展示涉及子使用案例的使用案例的状态流程图的实施例。状态流程图与图4描绘的状态流程图等效，其中循环的本体，事件C和E，已经重新定义为可用于其它使用案例的状态流量图中的子使用案例。\n[0151] 为了评估使用案例是否已经成功完成，可能不仅仅考虑结束状态。并非严格地依赖于结束状态，使用案例图的任何状态可设定可采用如OK、“报警”(WARNING)或“出错”(ERROR)的值的状态标志。状态标志可在各个状态之间结转直至使用案例结束。这允许了快速评估在执行使用案例期间是否发生任何问题。举例来说，图5的子使用案例的状态E可指示已经发生非关键问题，以及将状态标志设定为“报警”。当达到主要使用案例“结束”状态G时，此信息将为可利用的并且允许标记使用案例以供手动深入分析，即使最终状态G指示使用案例成功完成也是如此。也可清除状态标记。这在成功处置由使用案例所预期的问题的情况下至关重要。\n[0152] 图6展示包括使用变量的子使用案例的多实例使用案例追踪的实施例。考虑以下具有参数P1和P2的一系列记录消息A-E，其中A-E由其部件ID和消息ID来唯一地定义，并且P1和P2用作在记录时间写入相应记录消息的元数据中的ID。在正确的匹配使用案例定义采用如图6说明的变量的情况下，可自动识别两个并发实例，方法是在将记录消息与具体状态匹配时将参数P1或P2中的至少一个值分配至相应变量并且在将另一记录消息与另一具体状态匹配时将参数P1或P2中的至少一个值与相应变量比较。附图指示将参数分配至变量$ID和$ID2(:=符号)，为了将状态与消息匹配(==符号)所需满足的必须条件，以及经由$RETURN将来自子使用案例的变量传送至其母体使用案例。通常，用于使用案例定义中的变量为全局类型。图中的参数A、P1、P1和P2的值可从包括于每个记录消息的元数据中的参数提取，如果所述参数可获得。\n[0153]\n消息 A A B B C C D D E E\nP1 1 2 1 2 - - 3 4 - -\nP2 - - 3 4 4 3 - - 3 4\n[0154] 表4：消息序列\n[0155] 表展示在多实例情况下一系列记录消息的实施例以及参数P1和P2的值。在这类情况下，分析器部件通常接收这类无序列表(相对于相应使用案例的实例)并且尝试识别使用案例的每个实例，方法是将包括于至少一个记录消息的元数据中的至少一个参数的值与使用案例的至少一个变量匹配。将两个实例(1)和(2)初始化，方法是将上述表中的前两个记录消息与预定义使用案例的“开始”状态匹配。当进入子使用案例时，分析器部件识别每个记录消息B的实例，方法是将包括于当前记录消息的元数据中的参数P1的值与在初始化步骤期间在匹配“开始”状态时存储于变量$ID中的值进行匹配。针对所有以下状态进行类似匹配，这样使得分析器部件可成功地将每个所提取的记录消息分配至使用案例的正确实例。举例来说，首先从记录文件中提取涉及第二实例(2)的记录消息(C,-,4)，但是经由将P2与$ID2匹配，分析器部件能够识别使用案例的正确实例(2)。\n[0156] 两个并发使用案例实例通过包括参数P1和P2的以下一系列记录消息来唯一地识别：\n[0157] (A,1,-),(B,1,3),(C,-,3),(D,3,-),(E,-,3)\n[0158] (A,2,-),(B,2,4),(C,-,4),(D,4,-),(E,-,4)\n[0159] 在执行实际记录文件分析之前，可检查使用案例图的语法正确性。这可包括，例如，有效的使用案例必须具有至少一个“开始”状态、至少一个“结束”状态、零个或更多个“事件”状态、引用零或更多个子_使用案例(SUB_USECASE)(在存在时)、明确定义的使用案例图、正确的变量声明和使用等。验证可包括将存储在存储器中的可利用信号ID与和使用案例状态相关的那些信号ID比较。每个信号必须具有相应使用案例状态。否则这些信号标记为未使用的记录消息。当例如使用图形工具来定义使用案例时，可自动执行语法检查。语法检查还可通过将描述使用案例的XML实例相对于其XML模式验证来执行。在这种情况下，XML模式可包括可获得记录消息、参数和变量的所有定义，同时限制或不限制其关系。\n[0160] 在自动处理记录文件期间，分析器可尝试识别尽可能多的预定义使用案例。对于每个使用案例，只要状态具有一个以上后续状态，可存在多个流动路径。即使在所分析的记录文件中发现匹配一个分支中的状态的记录消息，分析器部件可仍然尝试完成其它分支的路径。举例来说，在图5的使用案例中，记录文件中可首先出现顶部分支B、D中的两个状态。\n然后，在状态A之后，可发生右分支中的子使用案例。为了正确追踪多个流动路径并行活动的使用案例，可能会需要处理许多分支，所述流动路径可能或可能不取决于彼此并且不能由建模程序按顺序放置。因此，重要的是，应注意虽然箭头指定流动路径内部的状态的排序，但是不同路径中的状态之间没有具体排序，而状态必须在已经发生分支的状态之后发生除外。\n[0161] 对于具有一个以上后续状态的每个状态，可检查新的流动路径。一旦已经在所有流量路径中搜索事件，使用案例通常才视为经过完全分析的。此外，可能需要使用案例所记录的最后一条线为“结束”状态。因此，一旦使用案例不具有除“结束”状态以外的后续状态，在处理对应于“结束”状态的记录消息之前检查其它分支。\n[0162] 图7描绘远程信息处理使用案例的实际表现。图7定义从后端服务器下载文件的使用案例。包括用于保留并且释放网络访问资源的子使用案例，以及实际下载子使用案例。图\n7还示出经由变量来追踪使用案例以供识别使用案例实例。参数和变量的匹配以及参数和值/值范围遵循表1中定义的标准。“获得网络资源”子使用案例的正确实例通过引用子使用案例呼叫($R-ID)中的文件($F-ID)的识别符来识别。此变量的值与来自子使用案例开始状态的相应记录消息的元数据的相应参数匹配。在下载子使用案例中，$DL-ID变量用于再次从第一消息参数中提取下载识别符值，并且因而允许正确识别相应“结束”状态的实例。此外，说明了定义不具有进入路径的结束状态的技术，从而指示可从任何其它非结束状态来达到结束状态。\n[0163] 下文提供图7所呈现的表现的可能记录文件内容的实施例，其中考虑两个并发文件下载。在本文中，第一下载失败。由于图7的决定性的使用案例定义，分析器部件正确地跟踪两个实例。\n[0164]\n[0165] 表5：具有两个并发文件下载的消息系列的实施例\n[0166] 两个并发使用案例实例唯一地识别为：\n[0167] 第一下载(失败) (最终标记状态“出错”)\n[0168] 第二下载(成功) (最终标记状态OK)\n[0169] 下文描述多级别字典的示例性格式，其包括含有全局消息过滤器的最高级别描述文件和特定于部件的翻译文件的输入语句。为了避免任何冲突，还在最高级别文件中定义相关部件ID。\n[0170]\n[0171]\n[0172] 部件级别翻译文件将文本消息分配至相应信号ID。文本消息可包括占位符以用于插入来自每个消息帧的消息元数据字段的解译内容。下文提供部件级别翻译文件采用的格式。\n[0173]\n[0174] 对于表2的简单二进制记录格式，表6定义了占位符。这确定如何解译二进制元数据(参数1-3)。C-型式枚举可经过定义并且用于将整数翻译成更可读格式。\n[0175]\n[0176] 表6：占位符的定义\n[0177] 下文给出枚举定义的实施例和在特定于部件的翻译文件中的用法：\n[0178]\n[0179] 多级别字典还可以Python字典或Perl杂凑形式来提供。