CN101438238A

CN101438238A - 用于异常检测的方法和系统

Info

Publication number: CN101438238A
Application number: CNA2005800432875A
Authority: CN
Inventors: 威廉·L·米勒; 德拉甘·德朱德赞诺维克; J·刘
Original assignee: Robert Bosch GmbH; ETAS Inc
Current assignee: Robert Bosch GmbH; ETAS Inc
Priority date: 2004-10-15
Filing date: 2005-10-14
Publication date: 2009-05-20
Also published as: WO2006044760A3; JP2008517386A; EP1825360A2; US20060101402A1; WO2006044760A2

Abstract

一种用于检测异常的系统包括第一硬件系统和第一运行时环境。所述第一硬件系统产生输出。所述第一运行时环境具有到集成开发环境的双向链接。所述第一运行时环境包括第一控制系统、第一诊断代理和第二诊断代理。所述第一控制系统通过给所述硬件系统的控制输入来控制所述硬件系统。所述第一诊断代理检测所述硬件系统中的异常。所述第二诊断代理检测所述控制系统中的异常。一种用于在包括通过链路双向连接的集成开发环境和运行时环境的系统中检测异常的方法包括：将所述运行时环境分区为至少一个操作区域，学习所述操作区域内的正常操作行为，在系统操作期间监控所述操作区域内的当前操作行为，比较当前操作行为与正常操作行为，在当前操作行为与正常操作行为之间存在偏离时检测出异常，将异常追溯回集成开发环境，以及基于异常的追溯识别出集成开发环境中的异常。

Description

用于异常检测的方法和系统

技术领域

本发明涉及软件和系统，并且更具体地涉及在运行时环境中的异常检测器。

背景技术

在产品开发的当前范例中，在开发期间，主要设计、测试和实现产品、产品的生产、以及产品的服务的质量。产品、产品的生产或产品的服务中的错误在开发期间被识别出并被纠正。一旦产品被发布，就难以发现剩余的质量问题。

在汽车行业中，保修是昂贵的并且会消耗公司的利润。工艺技术是多于百分之五十的保修费用的根本原因。在车辆中运行的软件是工艺技术问题的核心部分。由于工艺技术经常是该问题的根本原因，所以在修理过程中替换零件将不解决问题。因此，希望进行改进。

发明内容

根据本发明，上述和其它问题通过下面的方案来解决：

在本发明的一个方面中，一种用于检测异常的系统包括第一硬件系统和第一运行时环境。所述第一硬件系统产生输出。所述第一运行时环境具有到集成开发环境的双向链接。所述第一运行时环境包括第一控制系统、第一诊断代理和第二诊断代理。所述第一控制系统通过给所述硬件系统的控制输入来控制所述硬件系统。所述第一诊断代理检测所述硬件系统中的异常。所述第二诊断代理检测所述控制系统中的异常。

在本发明的另一个方面中，披露了一种用于在包括通过链接双向连接的集成开发环境和运行时环境的系统中检测异常的方法。该方法包括：将所述运行时环境分区为至少一个操作区域；学习所述操作区域内的正常操作行为；在系统操作期间监控所述操作区域内的当前操作行为；比较当前操作行为与正常操作行为；在存在当前操作行为与正常操作行为之间的偏离时检测出异常；将异常追溯回集成开发环境，以及基于异常的追溯识别出集成开发环境中的异常。

在本发明的另一个方面中，披露了一种计算机程序产品，所述计算机程序产品可由计算系统读取，并且对计算机进程的指令进行编码，该计算机进程用于在包括通过链接双向连接的集成开发环境和运行时环境的系统中检测异常。所述计算机程序产品包括：将所述运行时环境分区为至少一个操作区域；学习所述操作区域内的正常操作行为；在系统操作期间监控所述操作区域内的当前操作行为；比较当前操作行为与正常操作行为；在存在当前操作行为与正常操作行为之间的偏离时检测出异常；将异常追溯回集成开发环境；以及基于异常的追溯识别出集成开发环境中的异常。

在本发明的另一个方面中，披露了一种用于在包括通过链接双向连接的集成开发环境和运行时环境的系统中检测异常的系统。所述系统包括分区模块、学习模块、监控模块、比较模块、检测模块、追溯模块以及识别模块。所述分区模块将所述运行时环境分区为至少一个操作区域。所述学习模块学习所述操作区域内的正常操作行为。所述监控模块在系统运行期间监控所述操作区域内的当前操作行为。所述比较模块比较当前操作行为与正常操作行为。所述检测模块在当前操作行为与正常操作行为之间存在偏离时检测出异常。所述追溯模块将异常追溯回集成开发环境。所述识别模块基于异常的追溯识别出集成开发环境中的异常。

本发明可以作为计算机进程、可以为分布式的计算系统、或者作为制造产品、例如计算机程序产品来实现。所述计算机程序产品可以是由计算机系统可读的并且对用于执行计算机进程的计算机指令程序进行编码的计算机存储介质。所述计算机程序产品也可以是在载波上的传播信号，所述载波可由计算系统读取并且对用于执行计算机进程的计算机指令程序进行编码。

本发明的更完整的理解和它的范围可以从以下简要描述的附图、本发明的当前优选实施例的以下详细描述、以及所附的权利要求中得到。

附图说明

现在参考附图，在附图中相似的参考数字始终代表相应的部分：

图1是根据本公开内容的一个典型实施例的、用于基于学习模型的生命周期诊断的方法和系统的示意性表示；

图2是可以被用于实现本公开内容的各个方面的计算系统的示意性表示；

图3是根据本公开内容的一个典型实施例的产品开发的方块图；

图4是根据本公开内容的一个典型实施例的、与恶劣的(wicked)问题相关的需求的示意性表示；

图5是根据本公开内容的一个典型实施例的、用于基于学习模型的生命周期诊断的方法和系统的示意性表示；

图6是根据本公开内容的一个典型实施例的、用于基于学习模型的生命周期诊断的方法和系统的示意性表示；

图7示出根据本公开内容的一个典型实施例的图形用户接口实例；

图8是根据本公开内容的一个典型实施例的示出分布式系统的示意图；

图9是根据本公开内容的一个典型实施例的示出车辆产品开发的进程图；

图10是根据本公开内容的一个典型实施例的示出螺旋形生命周期进程的进程图；

图11是根据本公开内容的一个典型实施例的示出螺旋形生命周期进程的进程图；

图12是根据本公开内容的一个典型实施例的示出车辆开发阶段的进程图；

图13是根据本公开内容的一个典型实施例的示出生命周期方法如何通过需求而发展的进程图；

图14是根据本公开内容的一个典型实施例的示出生命周期方法如何应用螺旋形子进程的进程图；

图15是根据本公开内容的一个典型实施例的示出生命周期方法如何被应用的进程图；

图16是根据本公开内容的一个典型实施例的示出生命周期方法如何发展的进程图；

图17是根据本公开内容的一个典型实施例的示出生命周期方法如何应用螺旋形子进程的进程图；

图18是根据本公开内容的一个典型实施例的示出在螺旋形子进程中如何应用生命周期方法的进程图；

图19是根据本公开内容的一个典型实施例的系统图；

图20示出根据本公开内容的一个典型实施例生命周期方法如何将各层面链接在一起；

图21是根据本公开内容的一个典型实施例的示出异常检测系统的进程图；

图22是根据本公开内容的一个典型实施例的异常检测系统的示意性表示；

图23是根据本公开内容的一个典型实施例的汽油发动机模型系统的示意性表示；

图24是根据本公开内容的一个典型实施例的集成控制系统、汽油发动机车辆模型系统、以及异常检测器的示意性表示；

图25是根据本公开内容的一个典型实施例的异常检测系统的示意性表示；

图26是根据本公开内容的一个典型实施例的异常检测系统的进程流程图；以及

图27是根据本公开内容的一个典型实施例的异常检测系统的进程流程图。

具体实施方式

在本发明的优选实施例的以下描述中，参考附图，该附图构成该描述的一部分，并且在附图中通过图解说明示出了本发明可以被实践的特定实施例。应理解的是，可以采用其它的实施例，并且可以在不背离本发明的范围的情况下进行改变。

本公开内容描述了用于基于学习模型的生命周期软件和系统的方法和系统。更具体地，所述软件和系统是自诊断的并且典型地包括嵌入式诊断代理。这些诊断代理可以包括异常检测代理和基于知识的代理。

所述系统可以包括集成开发环境(IDE)和链接在一起的运行时环境(RTE)。所述IDE包含一套在所述IDE内相链接的并被链接到所述RTE的开发工具。所述RTE包括许多在所述RTE内相链接的并被链接到所述IDE的诊断代理。由此，所述开发工具和诊断代理彼此通信。

现在参考图1，示出了一种基于学习模型的生命周期系统100的示意性表示实例。IDE 105包括一套在IDE 105内相链接的软件工具或代理。RTE 110包括另一套在RTE 110内相链接的软件代理。所述IDE105和所述RTE 110通过链路115相链接。

图2和下面的讨论意图提供可以实现本发明的适合的计算环境的简要、概括描述。虽然不是必需的，但是在由计算系统执行的计算机可执行指令、例如程序模块的一般上下文中描述本发明。一般，程序模块包括执行特定任务或实现特定抽象数据类型的例行程序、程序、对象、组件、数据结构等等。

那些本领域技术人员应理解，本发明可以采用其它计算机系统配置来实践，其中其它计算机系统配置包括手持设备、掌上设备、多处理器系统、基于微处理器的或可编程的消费电子设备、网络个人计算机、小型计算机、大型计算机等等。本发明也可以在由通过通信网络相连接的远程处理设备执行任务的分布式计算环境中被实践。在分布式计算环境中，程序模块可以位于本地和远程记忆存储设备中。

现在参考图2，用于实现本发明实施例的典型环境包括计算系统200形式的通用计算设备，该通用计算设备包括至少一个处理系统202。可以从多个厂商、例如Intel或Advanced Micro Devices获得多种处理单元。所述计算系统200还包括系统存储器204和将包括所述系统存储器204的不同系统组件耦合到所述处理单元202的系统总线206。所述系统总线206可以是几种类型的总线结构中的任何一种，这些类型的总线结构包括存储器总线或者存储器控制器、外围总线、以及使用多种总线结构中的任何一种的本地总线。

优选地，所述系统存储器204包括只读存储器(ROM)208和随机存取存储器(RAM)210。基本输入/输出系统212(BIOS)典型地被存储在所述ROM 208中，其中所述基本输入/输出系统包含例如在启动期间有助于在所述计算系统200内的元件之间传递信息的基本例行程序。

优选地，所述计算系统200进一步包括第二存储设备213、例如用于从(未示出的)硬盘中读取以及写入到硬盘中的硬盘驱动器和/或压缩闪存卡214。

所述硬盘驱动器213和压缩闪卡214分别通过硬盘驱动器接口220和压缩闪存卡接口222被连接到所述系统总线206。所述驱动器和卡以及它们的相关的计算机可读介质提供计算机可读指令、数据结构、程序模块和用于所述计算系统200的其它数据的非易失性存储。

虽然在这里所描述的典型环境使用硬盘驱动器213和压缩闪存卡214，但那些本领域技术人员应该理解，其它类型的能够存储数据的计算机可读介质可以被用于所述典型系统中。这些其它类型的计算机可读介质的例子包括盒式磁带、闪存卡、数字视频盘、柏努利(Bernoulli)盒式磁盘、CD ROM、DVD ROM、随机存取存储器(RAM)、只读存储器(ROM)等等。

多个程序模块可以被存储在硬盘213、压缩闪存卡214、ROM 208、或RAM 210上，该程序模块包括操作系统226、一个或多个应用程序228、其它程序模块230、以及程序数据232。用户可以通过输入设备234将命令和信息输入到所述计算系统200中。输入设备的例子可以包括键盘、鼠标、麦克风、操纵杆、游戏垫、圆盘式卫星电视天线、扫描仪、数码相机、触摸屏、以及电话。这些以及其它输入设备经常通过耦合到所述系统总线206上的接口240连接到所述处理单元202上。这些输入设备也可以通过许多接口、例如并行端口、串行端口、游戏端口、或者通用串行总线(USB)来连接。显示设备242、例如监视器或触摸屏LCD面板也通过例如视频适配器244的接口连接到所述系统总线206上。所述显示设备242可以是内部的或外部的。除了所述显示设备242之外，计算系统一般典型地包括其它外围设备(未示出)、例如扬声器、打印机、以及掌上设备。

当用在局域网(LAN)联网环境中时，所述计算系统200通过网络接口或适配器252连接到本地网络上。当用在广域网(WAN)联网环境、例如因特网中时，所述计算系统200典型地包括调制解调器254或其它装置、例如直接连接，用于通过所述广域网建立通信。所述调制解调器254可以是内部的或外部的，该调制解调器通过接口240连接到所述系统总线206上。在一个联网的环境中，关于所述计算系统200或其部分所描述的程序模块可以被存储在远程记忆存储设备中。应该理解，所示出的网络连接是示范性的，并且可以采用建立所述计算系统之间的通信链路的其它装置。

所述计算系统200也可以包括连接到所述存储器204上的记录器260。所述记录器260包括用于接收声音输入的麦克风，并且与所述存储器204通信以缓冲和存储所述声音输入。优选地，所述记录器260也包括记录按钮261，用于激活麦克风以及将所述声音输入传送到所述存储器204。

计算设备、例如计算系统200典型地包括至少一些形式的计算机可读介质。计算机可读介质可以是任何可用的能够被所述计算系统200访问的介质。例如，但非限制性地，计算机可读介质可以包括计算机存储介质和通信介质。

计算机存储介质包括以任何方法或技术实现的用于存储信息、例如计算机可读指令、数据结构、程序模块或其它数据的易失性和非易失性、可拆卸的和不可拆卸的介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其它存储技术、CD-ROM、数字通用盘(DVD)或其它光学存储器、盒式磁带、磁带、磁盘存储器或其它磁性存储设备、或任何其它能够被用于存储所希望的信息且能够被所述计算系统200访问的介质。

通信介质典型地包含计算机可读指令、数据结构、程序模块或调制数据信号、例如载波中的其它数据或其它传输机制，并且包括任何信息传递介质。术语“调制数据信号”意味着这样一种信号，该信号的特性中的一种或多种特性以对所述信号中的信息进行编码的方式被设置或改变。例如，但非限制性地，通信介质包括有线介质、例如有线网络或直接有线连接，以及无线介质、例如声波、射频、红外线以及其它无线介质。上述介质的任何组合也应该被包括在计算机可读介质的范围之内。计算机可读介质也可以被称作计算机程序产品。

图3是示出开发系统300的方块图，该开放系统可以包括软件和开发工具。在产品、例如车辆的开发过程中，所述开发系统300包括三种基本类型的组件。块310是需求组件。在产品和系统开发过程中的第一步骤使用所述需求组件。所述需求组件定义产品和系统将包括什么。块320是设计组件。在对产品和系统的需求被确定之后，所述产品和系统被设计成符合那些需求。块330是实现组件。在设计了产品和系统之后，所述产品和系统根据所述设计组件被制造并交付使用。所述系统也可以包括用于供应和服务链集成的企业应用。另外，所述系统可以包括运行时应用服务，所述运行时应用服务包括无线电通信、操作基础设施和车辆。

用车辆作为例子，汽车制造商决定利用用于基于学习模型的生命周期诊断的系统来制造新的模型X汽车。在块310处，确定对X汽车和系统的需求。例如，所述X汽车应该是具有一定有效载荷、加速度的私家轿车，并且不应超过20,000美元。所述系统应该减少保修费用并提高顾客满意度。

在块320处，所述X汽车和所述系统根据那些需求来设计。汽车的框架和悬架被设计成支撑所需的有效载荷，动力传动系统基于总车辆重量和加速度需求来设计或选择，并且所述X汽车的其余部分被设计成不超过20,000美元。例如，已知所述X汽车不应该超过20,000美元，工程师可以决定选择刚刚满足加速度需求的发动机，而不会选择将大大超过所述加速度需求的发动机。所述系统可以利用具有嵌入式网络平台的网络服务被设计成在由服务器、远程信息处理和嵌入在车辆中的电子设备组成的三层体系结构上运行。所述系统可以具有分布式数据库，以便使得能够遍及所述供应和服务链来定位服务器。所述系统可以包括开发、制造、和服务工具。

在块330处，所述X汽车和所述系统根据所述设计被实现，也就是被制造和交付使用。实现使用遍及所述供应和服务链中的三层体系结构的软件和硬件。

典型地，在产品和系统生命周期的每一步骤中使用软件，所述产品和系统生命周期包括产品和系统开发、生产和服务。车辆和系统的需求管理(RM)进程需要工具以促进所述供应和服务链中的人们之间的协作。当前，需求管理(RM)软件使用模型驱动的、面向对象(OO)的基于由人们编辑和收集的信息的工具。由于所述RM依赖于输入到其中的信息，所述RM是受限制的。因此，这些典型的RM工具不灵活并且在没人干预的情况下不能自发地识别错误。一些RM工具基于知识代理，从而给予它学习和识别错误的能力。这样的RM工具也不灵活。

在需求步骤中，存在两类决定要被分析的产品和系统的类型并且然后决定开发、生产和服务所需要的工具和进程的知识问题。这两类问题包括“温顺的”和“恶劣的”问题。大部分问题是温顺的，并能够采用基于阶段-关卡、线性进程和信息的工具来解决。开发对系统的需求以管理恶劣的问题需要基于螺旋形进程和知识的工具。

恶劣的问题由一组关联的议题和约束组成，并不具有关于问题本身的明确声明。在开发了表示候选解决方案的迭代原型之前，无法充分理解所述问题(以及因此对设计解决方案的需求)。在主要的线性的总开发过程中，需要用于迭代原型的次要的螺旋形进程。所述螺旋形进程包括每次在另一部分正被开放时“转出”软件的一部分。软件工程团体已经认识到螺旋形进程对于快速、有效的开发来说是必需的。

恶劣的问题的一个例子是汽车的设计和对汽车的诊断。术语“恶劣的”是由Horst Rittel于1970年提出的。Rittel发明了一种称为基于议题的信息系统(IBIS)的技术来帮助解决这类新问题。恶劣的问题看起来与构造不良的问题非常相似，但是却有很多对所述问题的观点可能不同的风险承担者。恶劣的问题必须利用螺旋形迭代进程来分析，并且意见、例如与所述问题相关的需求必须在新的范例400中被连接起来，如图4中所示。

参考图4，三个关键的IBIS实体是：(1)议题402、403、404或问题；(2)态度405、406、408或意见，其提供可能的解决方案或所述议题的解释；以及(3)论据410、412或者赞成的和反对的论据。所有的三种实体都可以通过关系、例如支持、反对、由......建议、响应、归纳、具体化、替换等等相关联。IBIS的可视化变成图表或网络。IBIS建立设计和形成知识管理核心的论证或意见表达对话之间的桥梁。

IBIS是一种具有语法的图形语言或一种论据映射形式。应用IBIS需要与实验设计(DOE)相似的技能。Jeffrey Conklin(http://cognexus.org/id17.htm)通过引入图形IBIS或gIBIS开辟了IBIS结构的图形超文本视图的应用。根据Conklin的观点，IBIS的实力源自三种特性：(1)IBIS将复杂的思维映射到分析结构图中；(2)IBIS暴露构成知识基础的问题；以及(3)IBIS图比其它信息形式更容易理解。

Compsim LLC以几种方式扩展了IBIS。在它们的IBIS工具体系结构中，意见可以以文本概要或者节点的树形结构的任一形式来详细说明。给定级别的意见可以具有优先权和权重以改变意见显示的排序。优先权可以容易地以多种图形方式来编辑。独特的决策机制利用支持否定论据的相对的增加和减少来模拟人类的思维。IBIS逻辑作为XML定义被捕捉并被用于建立基于知识的代理网络的连接网络。Compsim调用该代理结构知识增强电子逻辑(KEEL)。代理执行所述IBIS逻辑的扩展形式。

包含IBIS的当前领域被称作计算机支持的论证可视化(CSAV)。应用CSAV的相关领域是帮助产生互联网的计算机支持的协同工作(CSCW)和以计算机为媒介的通信(CMC)。CMC工具包括微软的NetMeeting^TM产品。

论证可视化是用于定义在需求管理中发现的复杂关系的关键技术，该需求管理是知识管理(KM)的子集。KM的原理之一在构造论者学习理论中找到，该理论要求通过协作对话来进行知识的协商构建。协商包括意见的比较测试。相对于与信息直接链接的知识的明确部分，具有意见可视化的相应对话创建包含最大知识部分的不言而喻的知识。不言而喻的知识对于共享的理解来说是必需的。

IBIS是一种基于知识的技术。用于需求管理的IBIS工具、例如Compenium^TM或QuestMap^TM(GDSS公司的商标)明显不同于用于RM的面向对象(OO)的框架工具、例如Telelogics的Doors^TM或IBM的Requisite-Pro^TM。不能容易地定义恶劣的问题，以便所有的风险承担者对要解决的问题或议题意见一致。存在在OO框架中不能利用RM工具容易地表示的权衡。IBIS允许用于定义需求的二元的境地(situated)情况。IBIS允许模拟需求。IBIS能够检测那些情况，并且确定哪组需求是适当的，或者所述需求是否恰好充分地适用于所述情况。

总之，当前的RM工具具有限制。OO RM工具使得能够在开发期间、而不是在生产或服务部署阶段期间实现需求、设计、和实现之间的可溯性。OO RM工具不是基于知识的，并且不能采用多个风险承担者的观点来容易地处理不良构造的、恶劣的问题，其中这些观点与作为论证的赞成观点和反对观点所表达的不同加权优先权等级的那些观点冲突。IBIS RM工具克服了那些限制中的大部分，但是并不为系统设计开发可追溯的需求。

OO RM和IBIS RM工具均认识到，在没有附加的结构、例如具有相关层级的大纲的情况下，单独以文本表达的意见之间的关系是不清楚的。例如那些通过超文本技术而成为可能的网络结构可以被追溯到Vannevar Bush和他1945年发表的文章《As We May Think》。在1962年，Douglas Englebart在他的斯坦福研究院的报告《AugmentingHuman Intellect：A Conceptual Framework》中定义了一种用于利用工具进行认知增加的框架。Englebart的研究和开发工作的成果是现代窗口、图标、鼠标、以及指针(WIMPT)图形用户接口(GUI)的开发以及基于超文本的工具的早期实现。

OO或者模型驱动的软件开发的往返工程(round-tripengineering)是可追溯回设计和需求元素的用于实现的源代码。往返是在需求、设计、和作为源代码的实现之间进行，然后返回到设计和需求。由于往返工程当前只在开发期间并且只在IDE的某些部分内进行，所以在开发之后在RTE内出现的模型错误不能被追溯回需求、设计、或实现中的根本原因。分割后的IDE可以包含四个象限。这些象限包含的方法和工具用于：(1)系统中的企业应用；(2)车辆的嵌入式软件；(3)车辆的远程信息处理；以及(4)车辆的服务系统。

经常地，OO模型采用统一建模语言(UML)来定义。UML是第三代OO图形建模语言。如在用例中所定义的那样，系统模型具有与称作参与者的外部用户交互作用的结构、行为、和功能方面。一个用例是系统的指定能力。系统需求典型地分成两种类别：功能性需求和非功能性或服务质量(QoS)需求。

功能性意味着系统应该做什么。QoS意味着功能有多好或功能的性能属性。在普通的用法中，功能性可以暗示功能和性能。所述结构方面定义在运行时可能存在的对象和对象关系。子系统、包、以及组件也定义可选的结构方面。所述行为方面定义结构元素在运行时系统中如何工作。UML提供状态图(有限状态机的正式表示)和活动图来指定操作和允许的先后顺序。活动图的一般用途是指定计算算法。随着时间的流逝，结构元素集合一起工作作为交互作用。交互作用是在顺序或协作图中定义的。

包含功能和QoS方面的系统的需求典型地通过以下两种方式中的任何一种或两种来捕获：(1)模型是具有在状态图和交互作用图中定义的详细需求的用例；或(2)作为文本的具有或不具有正式图、例如顺序图的技术规范，其尝试定义系统行为的所有可能的情况。

往返工程将OO需求经由OO设计追溯到包括软件的OO源代码的OO实现。该往返只在IDE的某些部分中并且只在开发期间发生，其中这些部分是OO IDE部分。目前，在开发、生产和服务期间，在RTE和IDE之间不存在往返可追溯性。往返工程已经被扩展为使用元模型，而不需要令人厌恶的源代码标记，但是扩展后的往返工程仍然只在开发期间在IDE的某些部分内发生。

基于模型的诊断是用于故障隔离的现有技术方法，该方法是用于识别车辆和系统的一个故障组件或多个故障组件的进程，其中该组件没有遵照作为车辆和系统的实现模型的一部分所指定的工作参数正常地工作。基于模型的诊断受到以下假定的限制，即模型没有错误并且精确地表示系统的所有操作情况。所述系统的操作情况包括所有预期的故障。

如果来自车辆的足够数量的可观测信息在运行时是可用的，则基于模型的诊断能够确定以前已知的和预期的故障模式的根本原因，所述以前已知的和预期的故障模式是由包括正常和故障模式的扩展模型所预测的。所述扩展模式被用于模拟和记录由所有可能的单个组件故障、然后由多个组件故障的组合所产生的行为。当观测到故障行为时，可以执行预定试验序列来确定根本原因。

车辆和系统的需求或设计以及实现模型中的故障主要是在开发之后由用户检测到的，这些用户可能抱怨并且由服务技术人员并且然后可能由工程师分析他们的抱怨。导致抱怨的情形经常是不容易被识别和再现的。故障隔离或根本原因确定的进程通常以检测到异常系统行为开始，并且尝试识别有缺陷的和不正确工作的一个组件或多个组件。这些组件在系统中执行某些功能集合。所述组件经常被设计为可包含软件的现场可更换的硬件单元。然而，在当前实施中所假定的故障模型考虑可更换的组件的功能故障模式，并且并不确定位于一个组件或多个组件内部的故障是硬件故障还是软件故障。如果所述故障是在软件中，那么所述故障是在需求、设计、或实现层面的模型故障。更换一个或多个硬件组件将无法补救该问题。

在一个示例实施例中，设想了一种检测车辆功能子系统中的生命周期故障并将故障追溯回模型中的根本原因的改进的方法和系统，这些故障是由硬件故障或由需求、设计、或实现的模型错误导致的。为了追溯故障，所述方法使用生命周期往返工程的新的能力，该能力将RTE中的诊断代理与IDE中的二元模型相链接，用于管理车辆功能和相应诊断的开发和维护。IDE中的二元模型由链接的二元工具管理，所述链接的二元工具在螺旋形开发“V”进程(稍后将更详细地描述)的每一级：需求、设计和实现开发功能和相应诊断。链接IDE和RTE的所述生命周期诊断方法可以在车辆RTE的开发、生产、和服务期间被应用。

参考图5和6，示出了一种基于学习模型的生命周期诊断系统499。优选地，所述系统499包括通过DRD连接599相连接的IDE 500和RTE600。图5是根据一个示例实施例的系统图，用于IDE 500中的车辆功能和相应诊断的开放以及RTE 600中的诊断部署以服务于车辆的生命周期诊断方法。该图示出了所述生命周期方法如何在IDE 500中利用链接将开发工具连接在一起。生命周期方法中的IDE 500包含用于开发车辆功能以及相应诊断应用的开发工具和进程，所述相应诊断应用由一套用于RTE 600中的部署的集成的和链接的诊断代理组成。所述IDE 500和所述RTE 600通过DRD链接599和相应进程连接起来。所述DRD 599可以包括数据库，该数据库可以是分布式数据库。

图6是根据一个示例实施例的系统图，用于IDE 500中的诊断开发以及RTE 600中的诊断部署以服务于车辆的生命周期诊断方法。该图示出所述生命周期方法如何在RTE 600中用链接将诊断代理连接在一起。生命周期方法中的RTE 600包含和运行作为三层系统部署的诊断应用，所述三层系统包括在服务器上运行的诊断代理、TCU或插入到车辆中的等价模块、以及ECU。生产服务工具与车辆对接并且是RTE 600的一部分。所述RTE 600通过所述DRD链接599和相应的进程被连接回所述IDE 500。

如图7中所示，例如Compsim KEEL工具包的IDE工具可以由在图5的DRD链接499中返回的数据驱动，以模拟和测试设计模型并分析故障模式。下面所显示的数据是由图5的IDE 500以XML定义的输入模式的实例；所述模式被存储在DRD链接599中：

-<Schema name＝＂KEELDataSchemaxml＂xmIns＝＂um:schemas-

microsoft-com:xml-data＂xmlns:dt＝＂um:schemas-microsoft-

com:datatypes＂>

-<ElementType name＝＂InDat＂content＝＂eltOnlt＂model＝＂closed＂>

</ElementType>

<ElementType name＝＂ProjectTTitle＂content＝＂textOnly＂

model＝＂closed＂dt:type＝＂string＂/>

</ElementType>

</Schema>

所述DRD链接599消除RTE代理600了解怎样与IDE 500中的工具进行通信的需求。所述系统499仅使用DRD链接599中的信息来创建所述IDE 500和所述RTE 600之间的适当的链接。数据从RTE 600返回到IDE 500的实例如下所示：

<？xml version＝＂1.0＂？>

-<Report xmlns＝＂x-schema:KEELDataSchemaxml.xml＂>

-<InDat>

</InDat>

-<InDat>

</InDat>

-<InDat>

</InDat>

-<InDat>

</InDat>

-<InDat>

</InDat>

-<InDat>

</Rcport>

再次参考图5，优选地，所述IDE 500具有针对系统499的用户的三个层面的开发活动，该系统499具有相应的工具和进程。这三个层面是需求管理、设计和实现。所述系统499在所述IDE 500中的每个层面为功能和诊断创建链接的二元工具对。

在图5的顶部是称作需求管理的活动。用于需求管理(RM)的典型的模型驱动的、面向对象(OO)的开发工具是IBM/Rational RequisitePro^TM和Telelogic DOORS^TM。所述生命周期方法通过利用基于议题的信息(IBIS)工具、例如Compsim Management Tool^TM(CMT)增加现有的OO RM工具来创建RM的新的二元能力。

所述IDE 500包括第一RM502、第二RM504、第一设计工具506、第二设计工具508、第三设计工具510、第一部署工具512、第二部署工具514、以及第三部署工具516。优选地，所述第一RM 502作为OORM工具来实现，并且所述第二RM504作为IBIS RM工具来实现。所述第一设计工具506作为OO模型驱动的功能设计工具、例如IBM/Rational Rose^TM、iLogix的Rhapsody^TM、MathWorks的Simulink^TM或ETAS的ASCET/SD^TM来实现。

所述第二设计工具508作为基于知识的诊断设计工具来实现。所述第三设计工具510作为基于模型的诊断设计工具来实现。所述第二设计工具508和第三设计工具510包含诊断创建器工具套装，所述诊断创建器工具套装包含基于知识的诊断设计工具和基于模型的诊断设计工具。这些工具使系统499的用户能够为相应的所设计的车辆功能开发运行时诊断代理。所述诊断代理被规定为运行在图6中的RTE 600的三个层面上。所述诊断创建器套装为每个诊断代理指定RTE 600的目标层面，并且在所述RTE 600的代理之间建立图6中所示的链接。基于知识的代理开发工具的例子是Compsim的KEEL^TM。基于模型的代理开发工具的例子是R.O.S.E.的Rodon^TM。

所述第一部署工具512作为软件功能代码产生、管理和部署工具、例如ASCET/SD^TM来实现。所述第二部署工具514作为软件诊断代码产生、管理和部署工具来实现。并且，所述第三部署工具516作为软件诊断代码产生、管理和部署工具来实现。

所述第一RM502通过链接518连接到所述第二RM504上。所述链接518是本领域中已知的任何标准通信链接。所述链接518是双向的、集成的链接，该链接能够捕获知识、设想以及在所述第一RM502中捕获的需求之后的判定逻辑。优选地，所述系统499通过将用于所述第一RM502中的对象的唯一的XML功能标识符描述符(FIDs-RM)传递到所述第二RM504并且通过利用XML诊断标识符描述符(DIDs-RM)建立数据关系来实现链接518。链接518的二元关系被存储在所述DRD链接599中。通过将所述第二RM504开窗到所述第一RM502的图形用户接口中，所述系统499使用户能够定义在作为所述第一RM502中的对象被捕获的需求之后的判定逻辑，例如用例。对应于所述第一RM502中的对象的所述第二RM504中的逻辑被定义为唯一的XML诊断标识符描述符(DIDs)。

所述第一设计工具506通过链接520被连接到所述第二和第三设计工具508、510上。链接520双向地传递设计(-D)的唯一的XML定义的功能标识符描述符以及设计(-D)的诊断标识符描述符，并且在设计层面集成分离的工具的图形用户接口。

所述第一部署工具512或功能模块通过链接522被连接到所述第二和第三部署工具514、516或诊断代理上。链接522双向地传递实现(-I)的唯一的XML定义的功能标识符描述符和诊断标识符描述符(-I)，以及集成实现工具的图形用户接口。链接522通过为对应于车辆模块的信息定义ECU存储位置和数据类型来实现。使用XML的ASAM MCD^TM就是这种链接的一个实例。例如ETAS的ASCET/SD^TM和INCA^TM的工具可以被用于实现链接522。

所述第一RM 502通过链接524也被连接到所述第一设计工具506上。所述第一设计工具506通过链接526也被连接到所述第一部署工具512上以用于实现。链接524、526使得能够在开发环境中针对功能实现往返工程。相应于需求的对象可以经由设计被追溯到实现中的源代码，并倒退到设计和需求。

同样地，所述第二RM工具504分别通过链接528、530被连接到所述第二和第三设计工具508、510上。所述第二和第三设计工具508、510分别通过链接532、534被连接到所述第二和第三部署工具514、516上。链接532、534使得能够在开发环境中针对诊断实现往返工程。用于诊断的XML定义的设计对象被连接到用于诊断的源代码。

所述系统499集成基于模型的诊断设计工具、例如R.O.S.E的Rodon^TM，该诊断设计工具利用工具、例如ASCET/SD^TM产生源代码，以在实时操作系统上产生可执行代码，以便在图6的RTE 600上实现。

参考图6，所述RTE 600具有三个层面的软件和硬件。使用所述IDE 500中的工具、所述DRD链接599、以及进程，所述系统499使得能够将诊断应用构建为运行在所述三个层面上的链接诊断代理的集合。利用OSGi^TM，可以将一些代理下载到层面2上。

所述RTE 600包括第一数据库602、服务器应用程序604、第二数据库606、中介器608、电子控制单元(ECU)610、学习代理612、以及代理612、614。优选地，所述第一数据库602是本领域中已知的嵌入式分布式数据库。所述服务器应用程序604是服务器诊断软件应用程序和KBD模块的网状网络。所述第二数据库606是嵌入式分布式数据库。所述中介器608管理诊断代理的KBD束和数据。所述ECU 610包括连接到所述ECU上的软件和其它硬件。所述学习代理612包括基于软件学习模型的诊断代理和ECU中的数据。所述代理614包括基于软件模型的诊断(MBD)代理和ECU中的数据。

所述第一数据库602通过链接616被连接到所述服务器应用程序604上。所述第二数据库606通过链接618被连接到所述中介器608上。所述ECU 610通过链接620被连接到所述学习代理612和代理614上。所述服务器应用程序604通过链接622也被连接到所述中介器608上。所述中介器608通过链接624被连接到所述学习代理612和代理614上。

IDE 500和RTE 600通过链接599相连接。链接599是开发、运行时、开发(DRD)链接。优选地，所述DRD链接599利用无线电通信和操作基础设施(TOI)来实现，所述无线电通信和操作基础设施包含分布式数据库和软件进程间通信(IPC)机制的组合。在所述DRD链接599中，通过所述数据库或IPC机制发送的信息用XML模式来定义并且包含IDE 500和RTE 600数据。所述XML模式可以在消息中被发送或者可选地被用于配置分布式数据库。

在开发期间，IDE 500中的新诊断工具被用于引导用户遵循螺旋形“V”进程沿着“V”来“上”和“下”，以便在需求、设计和实现层面上建立用功能标识符描述符(FIDs)唯一地标识的功能和用诊断标识符描述符(DIDs)唯一地标识的相应诊断之间的IDE模型链接(如下面更详细描述的)。具有FIDs和DI Ds的IDE二元(功能-诊断)模型链接被存储在所述DRD链接599数据库中。

从而当在开发期间所述方法在迭代的原型开发周期内遵循螺旋形“V”进程时，在所述IDE 500和所述DRD链接数据库599内建立新的二元系统模型。也为车辆构建了RTE 600。所述RTE 600包含三级层面的诊断代理，所述诊断代理一起被链接到集成诊断应用体系结构(DAA)中，并且利用ECU中的相应校准参数链接到包含软件的车辆功能上。

三级的RTE 600包括服务器604上的管理器和TCU上的中介器608，用于动态地将代理612、614部署到车辆上，例如将代理下载到车辆的TCU或车辆服务模块(VSM)中。

在所述RTE 600中，由代理管理器和中介器利用IDE定义的XML模式和数据、例如包含在所述DRD链接599中的FIDs和DIDs来执行软件对象之间的运行时链接或运行时绑定。这能够使代理链接在一起，并将代理与功能链接起来。

链接的一个实例是将诊断代理与发动机ECU中的校准参数相连接。在使用UML的IDE 500中，这些连接也可义包括端口和协议。在遵从自动控制和测量标准化协会(ASAM)的IDE 500和RTE 600中，将定义用于测量、校准和诊断(MCD)的涉及车辆中的ECU的附加访问方法。这些访问方法仍将被包含在所述DRD链接599中，并被表示为具有嵌入式数据的XML模式。

参考图8，生命周期诊断方法在分布式系统880中管理车辆。所述分布式系统包括数据库881、服务器882、车辆884、用于开发、生产和服务的工具886、888、890、以及位于车辆内部的模块、例如TCU 892和ECU 894。优选地，被所述方法用于定义系统的体系结构是ISO开放系统互连(OSI)的七层参考模型。这些层是应用层、表示层、会话层、传输层、网络层、数据链路层、以及物理层。DAA包含用于节点的七层“堆栈”的上面三层，并且TOI包含所述堆栈的下面四层。

根本原因追溯与生命周期往返工程一起进行，该生命周期往返工程将在图6的车辆RTE 600中检测到的故障与图5的IDE 500中的模型元素链接起来。链接通过使用存储在所述数据库中的IDE 500链接来实现。通过追溯在IDE 500中利用工具建立的链接，能够确定需求、设计和实现中的根本原因候选者。

螺旋形生命周期进程是由图6的车辆RTE 600中的协作的、自治的诊断代理所进行的可能的故障检测来触发的。所述代理将应用一系列的算法和技术，这些算法和技术可以被分成几种类别：基于模型的诊断(MBD)、基于学习模型的诊断(LMBD)或基于知识的诊断(KBD)。当前的OBD诊断代理使用MBD，所述MBD经常应用指数移动平均数来设计可接受的类型1和类型2的统计错误分布，其中指数移动平均数是一阶卡尔曼滤波器。

触发器可得到连接到图6的车辆RTE 600上的服务工具的辅助。触发器通过消息或分布式数据库向运行在一个或多个服务器上的车辆诊断应用发送信息。从车辆到所述服务器的消息或数据库事务是由车辆的TCU在从运行在ECU中的MBD和LMBD代理的组合以及运行在TCU中的MBD、LMBD和KBD代理的组合中得到信息之后创建的。

LMBD代理能够应用基于时间-频率的性能评估技术以避免将(具有错误的)模型用于过滤以及将信号检测为故障。时间-频率分析(TFA)方法提供一种用于管理一个信号或一个信号集的组合时间-频率表示的方法，其中该信号或该信号集表示系统的正常行为。所述行为可以随着时间和频率而发生变化。TFA是一种用于检测缓慢降级和突然故障的方法。最近开发的TFA方法能够使用时间序列或频谱分析以困难的或不可能的方式来识别系统签名的行为。TFA的最佳设计方法包括减少干扰分布或RID。RID优化实现提供高分辨率时间-频率表示的目的。利用RID TFA技术构建的学习MBD代理展示出许多想要得到的特性、例如在不使用模型的情况下非常快速的故障识别，同时具有最小限度的处理以及检测时的工程统计置信度。

再次参考图5和6，优选地，基于学习模型的生命周期诊断系统499包括IDE 500、IDE内的在IDE工具之间的链接、RTE 600、RTE 600内的链接、以及DRD链接599。与所述RTE 600内的代理和工具以及所述IDE 500内的工具一起工作的这些链接使所述系统能够将在所述RTE中检测到的故障或异常追溯回作为所述IDE中的模型错误的根本原因。

为了将模型故障从所述RTE 600追溯回所述IDE 500，所述方法执行所述RTE 600内的诊断代理和链接到所述IDE 500内的相应车辆功能上的诊断之间的往返工程。这些功能被表示为具有对象的模型。由于代理、进程、工具、以及链接在螺旋形进程中一起工作以学习在车辆生命周期内的模型错误，所述方法被称为基于生命周期学习模型的诊断。

除了用于所述车辆上的软件以及支持所述车辆的生产和服务的软件的RTE 600之外，IDE 500也是生命周期方法的组成部分。车辆的服务包括在经销商处的服务操作以及远程信息处理服务、例如OnStar^TM。优选地，所述RTE 600包括：车队，电子控制单元(ECU’s)，网络，传感器，致动器，用户接口设备、例如各个车辆上的仪表板上的里程计，包括例如分布式服务器的计算机、例如诸如WIFI之类的蜂窝无线局域网的通信网络的无线电通信和操作基础设施(TOI)，以及一些工具、例如通常可在OEM代理商和独立的配件市场(IAM)修理车间发现的诊断扫描工具。

优选地，所述IDE 500是具有用于开发和维护例如传动系电子设备之类的车辆功能的开发工具集合的计算实验室和试验驱动环境，所述动力传动系电子设备包括：ECU，传感器，用于发动机和传动装置的致动器，例如ECU、传感器之类的车身电子设备，以及用于照明系统的致动器，例如ECU、传感器之类的底盘电子设备，以及用于防锁制动系统(ABS)的致动器。车辆功能在一些系统、例如动力传动系和相应的子系统、例如发动机冷却装置中实现。这些系统和子系统包括硬件和软件。所述IDE 500也被用于开发企业应用软件(替代地叫作信息技术或IT软件)以支持车辆生产和服务操作。

实现车辆功能的软件通常运行于驻留在车辆上的电子控制单元(ECU’S)和可选的远程信息处理控制单元(TCU)上。应用软件运行于计算机、例如服务器和PC上，并用于例如诊断扫描工具的服务工具。用于服务操作的车辆诊断软件的开发通常称为创作。在所述车辆上的诊断软件被称为车载诊断(OBD)。

在图5的IDE 500的方法中所使用的进程在图9-18中被示出。当遵循这些进程时，IDE 500中的链接工具在所述DRD 599中建立信息，从而将RTE 600中的诊断应用及代理与IDE 500链接起来。那些代理读取DRD 599以找到与DIDs相链接的FIDs。

图9是根据本公开内容的一个典型实施例示出车辆产品开发生命周期900的进程图。车辆在其生命周期上的特定模型年的产品开发进程从概念上被分成三个阶段，包括开发阶段902、生产阶段904和服务阶段906。开发、生产和服务活动需要对大量软件进行管理。软件创建车辆功能的主要部分以及商业信息系统的主要部分，以支持车辆的生命周期。

包括用于生产和服务的工具的生产和服务能力的开发出现在开发阶段902期间。能力被定义为具有知识的人、工具、技术和进程。存在表示能力结构的相关的体系结构，包括用工具和技术表示的商业信息系统。在商业系统中存在大量软件。所述相关的体系结构也包括车辆的结构及其子系统，所述结构包括车辆的车载信息系统。在所述车辆中也存在车载诊断(OBD)系统。该OBD系统包括大量软件。政府法规要求所述OBD系统的一部分，以通过监视所述车辆的排放控制系统的操作来间接地监视所述车辆的排放。典型地，在车辆动力传动系ECU中几乎存在与控制软件同样多的诊断软件。

车辆上的信息系统典型地包括许多电子控制单元(ECUs)。车辆典型地具有五十个或更多个ECU。这些ECU包含大量软件。车辆的体系结构、以及它的生产和服务系统在开发期间被完整地定义。所述开发阶段902典型地以先前在研发(R&D)阶段(未示出)中所确定的体系结构的大部分开始，所述研发阶段是在所述开发阶段902之前进行的。用于车辆模型的体系结构模型典型地从平台模型中衍生出来，所述平台模型包括动力传动系、底盘体、以及其它子系统组件。

所述产品开发进程能够实现作为产品的车辆和商业系统的开发、生产和服务。所述进程利用在开发、生产和服务期间支持所述车辆的相应商业系统来起作用。

所述产品和商业系统由所述进程支持，所述进程是组织能力的一部分。所述能力具有相关的体系结构。所述体系结构涉及所述车辆和所述商业系统。所述能力包括内部和外部的(外包的)服务以及人们与他们的知识、应用程序、工具、平台、组件、以及技术。所述能力支持作为产品的车辆和在供应和服务链中的商业系统。这些链支持原始设备制造商(OEM)，以及在生命周期中支持作为产品的车辆。

车辆的生命周期典型地持续十年以上。所述开发阶段902大约是两到三年，随后的几年是用于几种模型年的生产阶段904。在所述生产阶段904之后是多年的服务阶段906。特定车辆的服务阶段906的初始部分典型地包括三年或更多年的原始设备服务(OES)保修期，在该保修期之后是包括独立配件市场(IAM)的服务期。

这些开发、生产和服务阶段902、904、906被示出为在时间上顺序地彼此跟随，但是存在重叠，这将在随后的图中被示出。所述生产阶段904以生产的启动(SOP)开始。所述服务阶段906以车辆的第一个顾客出货(FCS)开始。由于许多车辆是针对模型年而生产的，所述生产和服务阶段904、906重叠。

在所述进程的每个阶段902、904、906中，存在RTE和IDE。所述RTE是对于阶段是特定的。D-RTE 908表示开发RTE；P-RTE 910表示生产RTE；以及S-RTE 912表示服务RTE。具有生产工具的制造厂将被包括在所述P-RTE 910中。具有服务工具的OEM经销商的服务部门将被包括在所述S-RTE 912中。具有开发工具的单个IDE 914对于所有阶段是通用的，并被链接到每个特定的RTE 908、910、912。所述IDE 914将典型地被应用于供应和服务链、以及OEM和它的商业伙伴中。特定的RTE 908、910、912通过DRD链接916被连接到所述IDE 914上。

图10是根据本公开内容的一个典型实施例示出螺旋形生命周期进程1000的进程图，所述螺旋形生命周期进程在所述生命周期的图9的开发阶段902期间被用于生成原型周期。

产品开发进程的如图9所示的开发阶段902被用于开发具有螺旋形子进程1000的原型。子进程800适合于所述开发阶段902内部。所述车辆模型及其将被开发的支持商业系统由需求、设计和实现类别的组件组成。开发典型地以为所述车辆及其支持商业系统确定和指定需求模型的某些部分的活动开始，然后开发继续为所述车辆及其支持商业系统确定和指定设计模型的某些部分，所述开发包括具有其开发、生产和服务工具的RTE。

开发工具典型地支持设计模型的模拟，该设计模型使得能够在没有完全实现车辆和支持系统的情况下进行测试。具有例如环(HIL)中的硬件或环(SIL)中的软件之类的模拟和测试能力的开发工具被用于允许在能够获得完整的车辆之前对子系统进行增量开发。随着开发的进行，实现模型的某些部分能够被确定和指定。所述螺旋形进程被用来增量地完成需求、设计和实现的部分。所述螺旋形进程允许重复的前向序列、例如在设计之后的实现确定和指定或者反向序列、例如在设计或实现之后的需求开发。现代软件工程和相应的工具鼓励在开发过程中使用螺旋形进程，以加速开发、提高质量以及降低开发成本。

图11是根据本公开内容的一个典型实施例示出螺旋形生命周期进程1100的进程图，该进程具有同时发生的开发和服务操作的周期。

由于在车辆的生命周期的服务阶段期间将遇到缺陷和异常，所以需要所述生命周期螺旋形进程1100。缺陷是以前所分析的以及根据故障模式模型所预测的故障。用于确定根本原因的过程可能是已知的并能够被有效地应用。缺陷典型地能够通过修理过程在现场被纠正，所述修理过程包含调换或更换零件。

异常是以前没有分析过的并且根据故障模式模型没有预测到的故障。大部分异常的根本原因将是模型错误，例如软件错误。模型错误将在车辆和/或它的支持商业系统的实现中被发现。这些错误的纠正必须通过返回到开发阶段来执行。如所示出的那样，所述开发阶段与服务操作同时运行。

图12是根据本公开内容的一个典型实施例示出包含作为概念上的“V”周期的原型周期1200的车辆开发阶段的进程图。

图9的开发阶段902包括遵循“V”形的原型周期1200。所述“V”以按照需求开发车辆模型和商业系统的某些部分开始，然后可选地继续开发设计模型的部分，并且然后可选地继续开发实现模型的部分。在“V”的底部，开发活动的焦点于是转移到已经开发的模型的各部分的集成、测试、校准和确认。

“下降周期”位于图的左侧，而“上升周期”位于图的右侧。水平地穿过“V”的是将被集成、测试、校准或确认的模型的相应部分。在被部分开发之后，需求的组件可以通过类似于模拟的方法进行集成、测试和确认。早期原型“V”周期可能只包括需求的开发和测试。在设计或实现模型的某些部分已经被开发出来之后，模型的该部分可以与所述车辆和商业系统的模型的先前部分一起被集成、测试和确认。利用包括需求、设计和实现的组件，每个原型周期开发、集成、测试和确认模型的更多部分。

图13是根据本公开内容的一个典型实施例示出生命周期方法如何利用螺旋形进程经过需求、设计和实现而发展的进程图。

图9的开发阶段902发展经过原型开发周期1302、1304、1306。每个周期最初移动经过“V”周期的“下降周期”，所述“V”周期包括根据需求、设计以及实现的属性的模型的开发。在进入“上升周期”以开始测试和确认所述需求之前，早期的“下降周期”只需要开发需求。开发阶段中的大多数原型开发周期将包括根据“下降周期”中的需求、设计和实现的属性的模型的开发。

图14是根据本公开内容的一个典型实施例示出生命周期方法如何应用螺旋形子进程的进程图。

图9的所述开发阶段902包括原型周期1400。所述周期1400使用螺旋形进程以便如所示的那样最初在“下降周期”中移经所述“V”。利用所述螺旋形进程，原型模型的需求属性的部分被开发并且然后被测试，之后设计的部分被开发并且然后被测试，然后实现属性的部分被开发并且然后被测试。

图15是根据本公开内容的一个典型实施例示出生命周期方法如何利用链接的IDE和RTE被应用的进程图。

如图9所示，所述开发阶段902具有原型周期1500并且使用螺旋形进程以便移经所述“V”。在模型的开发部分中，需要IDE 1502。在实现模型的测试、校准和确认部分中，需要RTE 1504。为了有效地沿着所述螺旋形进程移动，所述IDE 1502和RTE 1504应该通过DRD链接1506进行连接。所述IDE 1502主要被应用于所述“V”的顶部和中部，并且所述RTE 1304被应用于所述“V”的底部。移经所述“V”的螺旋形进程由链接的IDE 1502和RTE 1504使能。在“下降周期”和“上升周期”期间需要链接。在所述“下降周期”中，信息流主要是从所述IDE 1502到所述RTE 1504，因为焦点在于以RTE 1504的实现结束。

图16是根据本公开内容的一个典型实施例示出所述生命周期方法如何发展的进程图。

图9的所述开发阶段902发展经过原型开发周期1602、1604、1606。每个周期最终移经所述“V”中的“上升周期”，所述“V”包括根据实现、设计、需求的属性的模型的集成、测试、校准和确认。早期的“上升周期”只包括需求。随后的“上升周期”包括需求和设计。开发阶段中的大多数原型开发周期将包括根据“下降周期”中的需求、设计、和实现的属性的模型的开发，之后是“上升周期”中的实现、设计和需求的集成、测试、校准和确认。

图17是根据本公开内容的一个典型实施例示出所述生命周期方法如何应用螺旋形子进程的进程图。

图9的所述开发阶段902包括原型周期。所述周期使用螺旋形进程1700以便如所示的那样最初在“下降周期”中并且然后在“上升周期”中移经过所述“V”。利用所述螺旋形进程，原型模型的实现属性的部分被集成并且然后被测试，之后设计的部分被开发并且然后被测试，然后需求属性的部分被测试并且然后被确认。

图18是根据本公开内容的一个典型实施例示出所述生命周期方法如何在螺旋形子进程中被应用的进程图。

图9的所述开发阶段902具有原型周期并且使用螺旋形进程1800来移经所述“V”。在模型的开发部分中，需要IDE 1802。在实现模型的测试、校准和确认部分中，需要RTE 1804。为了有效地沿着所述螺旋形进程移动，所述IDE 1802和RTE 1804应该通过DRD链接1806进行连接。所述IDE 1802主要被应用于所述“V”的顶部和中部，并且所述RTE 1804被应用于所述“V”的底部。移经所述“V”的螺旋形进程1800由链接的IDE 1802和RTE 1804使能。在“下降周期”和“上升周期”期间需要链接。在所述“上升周期”中，信息流主要是从所述RTE 1804到所述IDE 1802，因为焦点在于以具有需求集和IDE中的设计的确认模型结束。

如图19中所示，利用作为内部数据读取的特定DID-I构建的诊断代理能够检测所述RTE 600中的相应功能模块的故障。然后所述代理访问DRD 599以找到FID-I链接，从而将信息写入所述DRD 599中，该信息能够由IDE 500中的任何工具或RTE 600中的附加代理读取。如果所述代理在ECU中并且所述ECU不能直接访问所述DRD 599，则所述代理向TCU中的代理发送消息，其中所述TCU能够访问所述DRD599。

一旦链接到所述IDE 500，对功能块的诊断的往返工程利用由所述RTE 600在所述DRD 599中创建的信息所引导的所述IDE 500中的链接来使能。

如图20中所示，系统499使用第一和第二代理2012、2014来检测故障、缺陷或异常。所述第二代理2014是基于模型的诊断(MBD)代理，其可以使用模型和迭代过程来确定已知的故障模式的根本原因。这样的代理的例子是MBD代理，该MBD代理利用例如R.O.S.E.Rodon^TM的工具来构建。这些MBD代理对于在模型中没有预测到的新故障不是有效的。为了补偿检测能力的该缺陷，系统499创建和应用使用嵌入式数据挖掘算法、例如时间-频率分析(TFA)的第一代理2012或基于学习模型的诊断(LMBD)代理，该代理通过观测运行的车辆来学习模型。这些算法在特定的正常运行时间期间被训练和校准，并且然后在车辆RTE 600中在运行时在监视模式中被设置。

在系统499中，所述LMBD代理2012对由所述MBD代理2014检测到的故障的超集进行检测。LMBD故障可以被分类为：(1)可以在现场被修理的以前预期到的故障；或(2)新的故障，可能是模型错误或另一新类型的硬件故障。所述分类通过将所述MBD代理2014的输出和LMBD代理2012的输出进行比较而发生。如果所述MBD代理2014在采用统计置信因子之前已经注意到故障模式，那么所述故障可能不是模型错误。如果所述MBD代理2014具有指示以前没注意到的新故障模式的低的置信因子，那么需要对模型错误进行调查，并且服务技师被告知不要在现场调换零件。

当所述RTE代理将信息写入到图6的DRD链接599中时进行调查，该信息使图5的IDE 500将故障追溯回以实现、设计和需求层面所表示的模型层面。所述系统499识别哪些功能与所述故障关联。可以在图5的IDE 500中进行模拟以重复所述故障模式。所述模拟帮助确定根本原因。因此，所述LMBD代理2012能够检测异常。

图21是表示基于学习模型的诊断系统2100的逻辑操作的流程图。所述基于学习模型的诊断系统2100的操作流的入口以流连接2102开始。检测操作2104检测故障。值得注意的是诊断代理、例如以前在此描述过的那些诊断代理连续地监控车辆的功能。这样的代理一般位于在车辆上运行的RTE、例如图6的RTE 600内。发现模块2106确定是否已经发现了故障。如果所述发现模块2106确定没有发现故障，则操作流分支到通向检测操作2104的“否”。以这种方式，连续地对车辆进行监控。

如果所述发现模块2106确定已经发现了故障，则操作流分支到通向已知模块2108的“是”。所述已知模块2108确定所述故障是否为已知故障。如果所述已知模块2108确定所述故障是已知故障，则操作流分支到通向识别操作2110的“是”。所述识别操作2110识别所述已知故障的补救方法。操作流在端点2112处结束。

如果所述已知模块2108确定所述故障不是已知故障，则操作流分支到通向写操作2114的“否”。所述写操作2114将故障信息写到链接、例如图6的DRD链接599中。读操作2116从所述链接中读取所述故障信息。所述故障被读入所述IDE、例如图5的IDE 500中。模型操作2118识别可能是所述IDE的需求、设计或实现层面的错误的模型错误。操作流在端点2112处结束。

图22是示出诊断层2200的方块图，所述诊断层包括软件诊断代理2202和硬件诊断代理2204、例如图20的LMBD代理2012。所述诊断层2200可以在RTE、例如图20的RTE 600中运行。所述诊断层2200监控车辆系统2210。所述车辆系统2210包括控制系统2212和硬件系统2214。所述控制系统2212接收驱动器输入2216并向所述硬件系统2214提供控制输入2218。所述硬件系统2214提供车辆输出2220以操作车辆。

所述软件诊断代理2202监控所述控制系统2212。类似地，所述硬件诊断代理2204监控所述硬件系统2214。优选地，所述诊断代理2202、2204依照基于区域化的异常检测方案使用自组织映射和时间-频率分析来检测异常。当然，可以使用其它合适的方法。

自组织映射(SOM)定义矢量量化问题的非参数回归解决方案。这种非参数回归方法包括使多个有序离散参考矢量拟合于输入矢量样本的概率分布。SOM类似于矢量量化(VQ)技术，该矢量量化技术是一种传统的数据压缩方法，该方法通常利用有限数量的代码矢量或代码字

i＝1，2,...，k形成随机矢量

的概率密度函数p(x)的近似。对于每个代码字m_i，Voronoi集可如下被定义：

其包含为相应代码矢量mi的最近邻居的所有矢量。d(

)是在线性矢量空间

n上定义的距离量度，并且例如可以是众所周知的欧几里得距离。所有Voronoi集构造整个矢量空间

ⁿ的分区。因此，一旦根据某些优化准则确定了代码本，那么对于任何输入矢量x来说，它可以被编码为标量数字，该标量数字为索引c，其相关代码矢量在距离量度)产生最小值的意义上最接近于x，即：

c = \arg \min_{i} {d (x, m_{i})}

代码字

i＝1，2，...，k的最佳选择应该使平均期望量化误差函数：

E＝∫f(d(x，m_c))p(x)dx

最小化，其中f(·)是距离量度d(

)的某一单调递增函数。值得注意的是，所述索引c是输入矢量x和所有代码矢量

i＝1，2，...，k的函数。可以容易地观测到，c可以间断地变化。因此，关于

i＝1，2,...，k的期望量化误差E的梯度不是连续可微的。由于一般无法得到最小化的

i＝1，2,...，k的密集形式解，不得不迭代地接近最佳解。已经示出，在特定的情况下，当f(d(x，m_c))＝‖x-m_c‖²时，在

{- &dtri;}_{m_{j}} E |_{t} = 2 \cdot δ_{cj} \cdot (x (t) - m_{j} (t))

方向上在迭代步骤t可以获得最陡的下降，其中δ_cj是克罗内克δ符号函数。如果用包括来自梯度

{&dtri;}_{m_{j}} E |_{t} = - 2 \cdot δ_{cj} \cdot (x (t) - m_{j} (t))

的常量-2的学习速率因子α(t)定义步长，那么得到更新公式：

m_i(i+1)＝m_i(i)+α(t)·δ_ci·(x(i)-m_i(i))

获得的使平均期望量化误差E最小化的矢量集

i＝1，2,...，k可以将输入矢量空间映射到有限代码本参考矢量集中。然而，那些参考矢量的索引可以按任意的方式来安排，也就是所述映射仍然是无序的。其原因是，对于任何输入矢量x来说，它只能影响离它最近的代码矢量，因为使用了δ符号函数δ_cj。

不同于VQ技术，SOM能够将高维数据映射到更低维数的网格上，同时保留原始数据元素的最重要的拓扑和量度关系。相邻参考矢量的这种规律性来自于它们的局部的交互作用，也就是低维网格中的邻近节点在某一几何距离以下的参考矢量将彼此激活，以从相同的输入矢量学习信息。这导致对在相同邻域内的节点的参考矢量的局部平滑效应并导致全局排序。由于这种顺序特性，所述映射趋向于显示输入矢量空间所固有的自然聚类以及它们的关系。

所述SOM可以被解释为高维样本矢量空间到实际上由自组织节点集表示的一维或二维阵列的非线性投影。每个节点与具有和输入矢量相同维数的参考矢量相关联。在这篇报告中所使用的距离量度是众所周知的欧几里得距离。用于任意输入矢量的最佳匹配单元(BMU)被定义为：

c = \arg \min_{i} {| | x - m_{i} | |}

简而言之，与所述BMU相关联的参考矢量产生关于所述输入矢量x的最小欧几里得距离，为了确保在学习过程期间所述SOM的全局排序，不得不对所述输入矢量的影响区域进行扩展，而不是只更新所述BMU的参考矢量。一种替代方案是用新的邻域函数h_ci(t)替换δ符号函数δ_cj，所述邻域函数依赖于时间t和二维网格上的两个节点c和i之间的距离。这针对参考矢量给出下列公式：

m_{i} (t + 1) = m_{i} (t) + h_{ci} (| | r_{c} - r_{i} | |, t) \cdot (x (t) - m_{i} (t))

其中t＝0，1，...是离散时间索引，并且

是网格中的节点c和i的位置。

为了网络的收敛，有必要在t→∞时，使h_ci(‖r_c-r_i‖,t)→0。此外，网络的“弹性”程度涉及邻域函数h_ci(‖r_c-r_i‖，t)的平均宽度或“锐度”，其中随着‖r_c-r_i‖的增加，h_ci→0。h_ci(t)的最简单但有效的选择是：

其中N_c(t)是在二维网格中的节点c周围的具有指定半径的邻域集，并且α(t)是0和1之间的小的标量数字。α(t)和N_c(t)的半径是单调递减时间函数。所述邻域函数h_ci(t)的另一常用选择是：

h_{ci} (t) = α (t) \cdot \exp (- \frac{{| | r_{c} - r_{i} | |}^{2}}{{2 σ}^{2} (t)})

其中α(t)是学习速率因子，并且σ(t)定义h_ci(t)的宽度。它们都是单调递减时间函数。

对于小尺寸的SOM来说，那些参数的选择并不重要，例如，几百个节点。然而，对于非常大的SOM来说，不得不仔细地选择那些参数以保证参考矢量的收敛和全局排序。所述算法的计算步骤可以总结如下：

1.选择映射的尺寸和拓扑，通过随机地设置参考矢量

i＝1，2,...，k来对其集合进行初始化，或者例如选择第一训练矢量x的前k个拷贝。

2.为输入矢量x(t)找到BMU，并且调整BMU的参考矢量及其邻域单元。

3.重复步骤2，直到参考矢量的变化不重要为止。

如果在学习开始时假定所有训练样本都可以获得，则SOM的批量计算算法(Batch Map)也可以获得。尤其是当邻域N_c(t)收缩为只包含BMU的集合时在学习过程的最后阶段，它类似于VQ的K-means算法。该批量映射算法不包含学习速率因子，因此不存在收敛问题并且针对参考矢量

i＝1，2，...，k产生更稳定的值。

不同的学习过程参数、参考矢量

i＝1，2，...，k的初始化、以及训练矢量x(t)的顺序能够导致不同的映射。依赖于最优性准则，可以认为不同的SOM是最优的，例如平均量化误差。为‖x-m_c‖的平均值的平均量化误差是能够度量映射如何良好地适合于训练样本集的有意义的性能指标。关于SOM的进一步信息可以在下面的参考文献和其中的引用中找到，所有这些文献通过参考被合并于此：

Kohonen，T.，Oja，E.，Simula，O.，Visa，A.，Kangas，J.(1996)，“Engineering applications of the self-organizing map(自组织映射的工程应用)”，Proceedings of the IEEE，第84卷，第10期，第1358-1384页

Kohonen，T.(1995)，Self-Organizing Maps，Springer，柏林，海德堡。

日益复杂和完善的控制软件、集成的传感器、致动器、以及微电子设备给用户提供更高的可靠性、安全性和可维护性。然而，这些对现今的工程师们诊断车辆以及检测和隔离系统异常强加了比以前更多的挑战。车辆上的控制软件的增长部分使它变得更加困难，因为为了减少成本，大多数制造商优选设计更加完善的控制软件的解决方案，而不是增加硬件，来提供吸引人的特性。运行在车辆上的软件的数量在将来不太可能停止增长。

用在车辆上的控制软件和各种硬件组件通常展现出非线性行为。这对控制软件来说尤其是实际的。因此，一旦这些软件和硬件组件被集成在车辆中并且彼此进行通信，它们就创建大量的操作区域。那些交互作用有时甚至对于有经验的工程师来说都是过于复杂而难以理解的。此外，驱动器输入和外部环境条件大大变化，并且创建车辆运行的无限种条件模式。针对不同驱动器输入和外部影响描述系统行为的签名是完全不同的。在无限多的行为模式的情况下，异常检测和定位是复杂的，因为不得不将行为签名与适当的行为状态进行比较。发现异常的最好方式是在相同的行为状态内比较签名，并且当前签名与正常签名的偏差是异常的严重程度的指示。

为了将系统的动态行为划分到不同的操作区域中或区域化，首先不得不找到能够进行区域化的适当基准。物理系统的变型、例如机械、电气、电机、热、以及液压系统可以通过下列形式的普通微分方程进行建模：

F = (t, y, y', y'', . . ., y^{n}, u_{1}, u_{2}, . . ., u_{p}, u_{1}^{'}, u_{2}^{'}, . . ., u_{p}^{'}, . . ., u_{1}^{(m)}, u_{2}^{(m)}, . . ., u_{p}^{(m)}) = 0

其中是系统输出的一阶、二阶直至第n阶导数，并且

u_{1}, u_{2}, . . ., u_{p}, u_{1}^{'}, u_{2}^{'}, . . ., u_{p}^{'}, . . ., u_{1}^{(m)}, u_{2}^{(m)}, . . ., u_{p}^{(m)}

是输入以及它们的直至第m阶的导数。如果输入已经被指定为逐段可微的时间函数u＝μ(t)，其中u＝[u₁，u₂，...，u_p]，那么可以代入u＝μ(t)以消除u，并且它的导数产生：F(t，y，y′，y″,...，y⁽ⁿ⁾)＝0

y⁽ⁿ⁾可以被明确地表示，即

y^{(n)} = γ (t, y, y', y'', . . ., y^{(n - 1)}) .

如果选择如下的状态变量：x₁＝y，x₂＝y′，...，x_n＝y^(n-1)，则所述公式可以被写为一组状态空间方程：

{\overset{\cdot}{x}}_{1} = x_{2}

{\overset{\cdot}{x}}_{2} = x_{3}

{\overset{\cdot}{x}}_{n} = γ (t, y, y', y'', . . ., y^{(n - 1)})

y＝x₁

这可以作为一组n个一阶微分方程被重写为一个n维一阶矢量微分方程：

在通过参考被结合于此的Khalil，H.(2002)的“NonlinearSystems”(第三版，Prentice-Hall，NJ)中已经证明，如果f(t，x)在t上分段连续并且满足利普希茨条件：

‖f(t，x)-f(t，y)‖≤L‖x-y‖

其中L是有限正数，那么具有初始条件x(t₀)＝x₀的状态方程

在[t₀，t₁]内具有唯一的解。这称为全局存在性与唯一性定理。这可以容易地被推广到多输入和多输出系统。

如果满足一定的条件，直至(n-1)阶导数的输出y的初始条件以及在时间间隔[t₀，t₀+τ]期间的输入序列能够唯一地确定在相同时间间隔中的系统输出y。这就给我们一个指示，即所述区域化可以基于输出的初始条件和输入序列。

巨大数量的系统行为模式对异常检测和定位或区域化施加了巨大的挑战。传统的基于模型的缺陷诊断技术对于许多情形并不适用，因为无法获得关于基础物理系统的详细知识。所述系统只能被看成是黑盒。一些能够处理黑盒问题的可用技术不是具有严格的参数假定，就是缺乏实时实施性，例如非线性自回归移动平均建模和神经网络。因此，需要找到一种能够近似地建立涉及系统输入和输出的模型的方法。优选地，所述系统基于输入序列和输出的初始条件被分区为不同的区域。

如果我们将包括

的输出的初始条件与在某个时间间隔[t₀，t₁]期间的输入序列u(t)连接在一起以形成如下的大的矢量：

{[y (t_{0}), \frac{dy}{dt} |_{t = t_{0}}, \frac{d^{2} y}{{dt}^{2}} |_{t = t_{0}}, . . ., \frac{d^{n} y}{{dt}^{n}} |_{t = t_{0}}, u (t_{0}), . . ., u (t_{0} + τ)]}^{7}

其中

y (t_{0}) = [y_{1} (t_{0}), . . ., y_{q} (t_{0})], \frac{dy}{dt} |_{t = t_{0}} = [\frac{{dy}_{1}}{dt} |_{t = t_{0}}, . . ., \frac{{dy}_{q}}{dt} |_{t = t_{0}}]

等等。该矢量包含所有用于确定系统输出所需的信息。然而，在实际的应用中，该矢量通常具有很高的维数。因此，由于SOM的卓越的高维数据的可视化能力，所以SOM被用于对那些矢量所跨越的空间进行区域化。Voroni集使用训练后的SOM的所有参考矢量，然后形成所述矢量所跨越的整个空间的分区。Voroni集被称为系统的“操作区域”。

由于每个区域具有相似的输入和初始条件，相同操作区域中的输出序列将具有相似的模式。基于这些输出模式，可以为每个代表正常系统行为的操作区域创建统计分布。在区域化之后，基于输入模式和输出的初始条件，可以通过找到BMU将所述信号分配到适当的区域中，并且在每个区域内将当前输出序列与正常分布进行比较。当前输出序列和正常分布之间的统计不相似性量度可以被用作指示所述系统行为偏离正常的或期望的行为多远的性能指标。这可以通过基于时间频率分析的性能评估来实现。

时间频率分析法(TFA)长期以来被认为是强大的非信号处理方法，并且已经被广泛地应用于不同的领域、例如雷达技术、海洋生物学、以及生物医学工程。不同于众所周知的只能将信号分解为频率分量、但不描述时间位置相关信息的快速傅立叶变换(FFT)，TFA能够同时将信号分解为时间和频率。这使得TFA成为分析信号的合适方法，其中所述信号的频率内容随着时间而变化。例如，如果使用FFT，则检测控制系统中的时间延迟是非常困难的，但是使用TFA，则是较容易的任务。能够处理不稳定的信号使TFA非常适合于处理来自控制系统的信号。

考虑一个二维分布p_X，Y(x，y)，其特性函数如下给出：

φ(η，ξ)＝E[e^jXη+jγξ]＝∫∫e^jxη+jyξp_X，Y(x，y)dxdy

它可以用泰勒级数来近似，Cohen，L.(1994)，“时间-频率分析”，Prentice Hall，通过参考合并于此，并且所述特性函数可以被表示为：

φ (η, ξ) = Σ_{p + q = 0}^{N} \frac{j^{p + q}}{p! q!} E (X^{p} Y^{q}) η^{p} ξ^{q} + o [{(η^{2} + ξ^{2})}^{\frac{n}{2}}]

由于时间频率分布能够通过它的特性函数唯一地确定，所以矩序列E(X^pY^q)可以被用于描述所述分布p_X，Y(x，y)。

然而，所述矩序列是无限长的，因此不能直接被用作特征。此外，不同阶的矩彼此之间高度相关。不过，只有较低阶的矩描述时间频率分布的一般特性，因此可以将所述矩序列截短以便近似地表示时间频率分布。因此，需要进一步的处理以减少矩矢量的维数。这可以通过主成分分析(PCA)来实现，Richard，O.Duta，P.，David G.(2000)，“PatternClassification”，Wiley，第2版，其内容通过参考合并于此，由于时间频率矩可以被假定为渐近高斯，Zalubas，E.J.，O’Neill，J.C.，Williams，W.J.以及Hero，A.O.的“Shift and ScaleInvariant Detection”，Proc.IEEE Int.Conf.Acoustic，Speech，andSignal Processing，第5卷，1996，第3637-3640页，其通过参考合并于此。

假定主成分的高斯性(Gaussianity)和独立性，特征矢量之间的Mahalanobis距离渐近地遵循具有r个自由度的χ²分布，其中r是所提取的主成分的数量。因此，信号与表示正常分布的训练集之间的偏离可以通过Mahalanobis距离在某个范围内的概率来量度。所述概率被称作置信值(CV)，指示与正常状态的偏离程度。关于更多的详细信息，请参阅通过参考合并于此的Djurdj anovic，D.，Widmalm，S.E.，Willians，W.J.，Koh，C.K.H.和Yang，K.P.(2000)的“ComputerizedClassification of Temporomandibular Joint Sounds(颞下颌关节声音的计算机化分类)”，IEEE transaction on biomedicalengineering，第47卷，第8期。

图23根据一个示例实施例示出诊断系统2300，可以针对该诊断系统评估性能。系统2301包括输入2302、初始条件2304以及输出2306。区域化可以基于输入2302和初始条件2304使用SOM2308来完成。基于TFA的性能评估技术可以基于当前输出序列在操作区域2310内直接被应用。假定无法获得关于系统2301的模型或结构的知识。唯一的假定是当系统2301正常运行时输入2302和输出2306是可用的。

优选地，所述系统2301是车辆2320；然而，所述系统2320可以是任何适合的系统。图24更详细地示出车辆2320。所述车辆2320包括发动机2422、动力传动系统2424、其它组件2426、以及车辆动力2428。驱动器2430能够将输入2302提供到系统2301中，图23。环境2432也将输入2302提供到系统2301中，图23，例如温度、风速、路面斜度、以及气压。

为了将在此描述的异常检测技术应用于车辆2320，所述车辆2320必须被区域化为第一子系统2500，图25。在一个示例实施例中，所述第一子系统2500或区域化系统是节流板子系统2502。所述节流板子系统2502包括节流板控制器2504、节流板2506、控制器2508以及设备2510。

节流板子系统2502的输入、例如图23的输入2302是来自所述节流板控制器2504的控制信号2511，所述节流板控制器调节节流板2506中的节流板角度2516。实际的节流阀角度由传感器测量并且反馈到集成系统2500中。当车辆2320运行时，存在两种到所述节流板控制器2504的输入：相对加速器位置2512和发动机速度2514。基于这两种输入2512、2514，所述节流板控制器2504计算控制信号2511，并把它发回到设置绝对节流阀角度2516的节流板2506。

当系统2502运行时，异常检测系统2550检测所述设备(节流机构)2510或所述控制器2508的逐步参数退化。此外，所述异常检测系统2550应该能够定位任何异常，而不管所述异常是发生在控制器2508内还是发生在所述设备2510内。优选地，所述异常检测系统2550包括第一异常检测器2552和第二异常检测器2554。所述第一异常检测器2552在控制侧检测异常，而所述第二异常检测器2554在设备侧检测异常。

所述相对加速器信号(Accelerator)2512、发动机速度(n_Engine)2514、控制信号(al_ThrottleECU)2511、以及绝对节流阀角度(al_Throttle)2516被频繁地采样，优选地每5毫秒进行一次采样，这相当于大约200Hz的采样率。优选地，这些信号然后被降低一半的采样率，以将采样率降低到100Hz。

当所述车辆2320在正常条件下运行时，或者在IDE、例如图5的IDE500中被确定时，首先收集相对加速器信号(Accelerator)2512、发动机速度(n_Engine)2514、控制信号(al_ThrottleECU)2511、以及绝对节流阀角度(al_Throttle)2516。

下表示出训练和测试数据集：

	测试周期的名字
	测试周期的名字	训练数据集	Ja pan 15 & Japan 11：日本的周期FTP72：USA(1972年的联邦测试程序)手动驱动简档
测试数据集	FTP75：USA(1975年的联邦测试程序)ECE2：ECE的新欧洲测试周期	训练数据集	Ja pan 15 & Japan 11：日本的周期FTP72：USA(1972年的联邦测试程序)手动驱动简档

下图示出在车辆2320内的机械节流板2506：

子系统2500的输入被标记为al_ThrottleECU 2511，它是来自所述节流板控制器2504的控制信号2511，通常在0～1之间变化。通过改变al_ThrottleECU信号2511，可以调节被标记为al_Throttle 2516的所述节流板2506的输出，如上所示，该输出是相对于停止的绝对节流阀角度。两个参数al_ThrottleMin和al_ThrottleDelta定义所述节流板2506能够打开的范围。所述节流板2506的动态被建模为具有以下三个参数的二阶动态系统：质量M、粘性阻尼系数C、以及硬度K。所述节流板2506的参数的标称值是：M＝1，C＝10，K＝40，al_ThrottleDelta＝80，且al_ThrottleMin＝8。

下图示出在节流板2506的所有参数被设置为标称值时所收集到的信号：

[\begin{matrix} y (t_{0}) \\ \frac{dy}{dt} |_{t = t_{0}} \\ \frac{d^{2} y}{{dt}^{2}} |_{t = t_{0}} \\ \cdot \\ \cdot \\ \cdot \\ u (t_{0}) \\ \cdot \\ \cdot \\ \cdot \\ u (t_{0} + τ) \end{matrix}] \cdot \cdot \cdot \begin{matrix}  \end{matrix} [\begin{matrix} y (t_{1}) \\ \frac{dy}{dt} |_{t = t_{1}} \\ \frac{d^{2} y}{{dt}^{2}} |_{t = t_{1}} \\ \cdot \\ \cdot \\ \cdot \\ u (t_{1}) \\ \cdot \\ \cdot \\ \cdot \\ u (t_{1} + τ) \end{matrix}] \cdot \cdot \cdot

[\begin{matrix} y (t_{0}) \\ \cdot \\ \cdot \\ \cdot \\ y (t_{0} + τ) \end{matrix}] \cdot \cdot \cdot [\begin{matrix} y (t_{1}) \\ \cdot \\ \cdot \\ \cdot \\ y (t_{1} + τ) \end{matrix}] \cdot \cdot \cdot

如上所述，系统动态行为被划分到不同的操作区域中，并且在每个区域内，训练是必要的以使用输出序列建立统计正常分布。该训练信息可以是通过所述DRD链接599从IDE、例如图5的IDE 500学习的信息。所述节流板子系统2500的区域化基于输出的初始条件以及输入序列，其中输出是绝对节流阀角度(al_Throttle)2516，所述输入序列是来自所述节流板控制器2504的控制信号2511，即al_ThrottleECU 2511。

al_ThrottleECU被表示为u且al_Throttle被表示为y。为了包括所有关于输出的初始条件以及输入的信息，将它们一起连接到一个大的特征矢量

{[y (t_{0}), \frac{dy}{dt} |_{t = t_{0}}, \frac{d^{2} y}{{dt}^{2}} |_{t = t_{0}}, . . ., u (t_{0}), . . ., u (t_{0} + τ)]}^{T}

中，其中

是系统输出的初始值、一阶导数和二阶导数等等。u(t₀)，...，u(t₀+τ)是在时间间隔[t₀，t₀+τ]期间的输入序列。相应的输出序列是[y(t₀)，...，y(t₀+τ)]T。同样地，可以将长度为τ的窗口转移到另一个起始点t1，如所示的那样产生另一个大的特征矢量

{[y (t_{1}), \frac{dy}{dt} |_{t = t_{1}}, \frac{d^{2} y}{{dt}^{2}} |_{t = t_{1}}, . . ., u (t_{1}), . . ., u (t_{1} + τ)]}^{T}

及其相应的输出序列[y(t₁)，...，y(t₁+τ)]^T。这样，就收集了两个矢量集合：一个包含关于输出的初始条件以及输入序列的所有信息，另一个包括相同时间间隔的输出序列。此外，在这两个特征矢量集合之间存在一对一的对应关系。

只有具有高度动态的输入的信号被用于训练并且稍后被用于测试。相对静态的输入不能模拟系统的动态模式，因此不能揭示由于动态系统参数漂移所导致的缺陷。因此，为了检测系统的增益变化以及动态范围，使用只快速改变的信号的训练集。一种可能的方式是设置输入序列的方差的阈值。只有方差大于预定阈值的输入序列被选择作为训练集。虽然这可能不是最佳的方式，但是它更容易实现。

在收集了所有的特征矢量之后，可以基于由输入序列和输出的初始条件组成的矢量利用SOM进行区域化。在所述节流板子系统2502的该示例实施例中，数据序列长度被选择为0.6秒，这相应于在如上所述原始数据被降低一半的采样率之后的60个点。对于输出的初始条件来说，只包括初始值、以及一阶和二阶导数。由于到所述节流板子系统2502的输入是介于0～1的数字，所以不需要对输入序列进行归一化。包括初始值、一阶和二阶导数在内的输出的初始条件已经利用下面的公式被归一化：

X_{normalized} = \frac{X - E (X)}{σ_{X}}

其中E(X)和σ_x是变量X的均值和偏差。需要进行该步骤来消除在特征矢量元素中存在巨大幅度差异的情况，因为大幅度的特征将支配对所得到的SOM的影响。能够被使用的示例软件包是SOM工具箱，Alhoniemi，E.，Himberg，J.，Kiviluoto，K.，Parviainen，J.以及Vesanto，J.(1997)，SOM toolbox for Matlab(通过WWW可以在fttp://www.cis.hut.fi/somtoolbox/找到。

基于可用的训练矢量的尺寸利用嵌入在软件内部的启发式公式可以确定SOM的尺寸。在SOM的概化(generalization)程度和量化精度之间存在权衡。小的SOM具有训练特征矢量的良好的概化，但是具有差的量化精度。大的SOM能够具有高的量化精度，但是训练特征矢量不能很好地被概化，并且它消耗更多的计算功率。从输入和输出的初始条件的连接特征矢量获得的SOM以及统一距离矩阵如下被示出：

U矩阵

创建的SOM基于通过将系统输入、输出的初始条件以及统一距离矩阵相连接所获得的特征矢量。

一旦利用正常数据完成了SOM训练，正常训练输出序列然后就可被分配到相关原型特征矢量最接近于输入和初始条件的相应连接特征矢量的区域。TFA然后被应用于每个区域中的正常训练输出序列，并且矩序列被提取。

基于时间频率分布，矩被计算到15阶，也就是p+q≤15。这导致维数为135的矩序列。为了减少所获得的矩序列的维数，在每个区域内，PCA被应用于这些矩序列，以进一步压缩高维矩序列。最后，只有2～3个主方向，沿着所述方向，原始矩序列投射的总方差的99％以及它们的相应的方差作为稍后测试的参数被保存。为了确定所述训练是充分的以及保持高的检测准确度，只选择在训练期间已经被频繁激活过的区域，并且在这些区域中的每一个中基于上面描述的过程进行所述训练。

图26示出异常检测器2600的逻辑流程图。操作流开始于开始端2602。输出操作2604针对到达的任何新信号基于当前输入序列和初始条件的连接特征矢量将当前输出序列及其相应的输入和初始条件分配到一个操作区域，所述操作区域的代码字矢量最接近于连接特征矢量。计算操作2606计算量化误差。

误差模块2608确定所述量化误差是否小于预设阈值，所述预设阈值是训练期间的量化误差的中值。如果所述误差模块2608确定所述量化误差较小，则操作流分支到通向输出操作2604的“是”。如果所述误差模块2608确定所述量化误差不是较小，则操作流分支到通向异常操作2610的“否”，并且异常检测器被触发。所述异常检测器将自动检索指定区域的训练参数，并且根据χ²分布计算由当前输出序列计算出的矩序列所指定的Mahalanobis距离的累计概率。输出操作2612输出具有变化范围在0～1之间的置信值的性能指标，该性能指标量度系统行为与正常行为的偏离。操作流在端点2614处结束。

下图示出节流板子系统2502上的异常检测器的一些示例结果：

衰减(设备) 衰减(设备)

其表示当系统参数被设置为如沿着x轴所指示的指定值时置信值的平均值。此外，3-σ界限也被示出为由短实线实现的间隔。如以前在此所讨论的那样，粘性阻尼系数C和硬度K的标称值分别是10和40。可以观测到，当所述参数从标称值退化时，所述置信值降低。这又提供系统性能偏离正常行为的指示。针对另外两个参数：质量M和ThrottleDelta，也观测到了相似的趋向。这表明所述异常检测器在不预先提交表征那些缺陷的签名给异常检测器的情况下能够检测不同种类的异常和系统参数的逐步退化。

不同于只有一个输入的图25的节流板2506，节流板控制器2504具有两个输入：Accelerator 2512和n_Engine 2514。可以将参数引入到所述节流板控制器2504中，以便缩放非线性节流板控制器2504中的表格之一。增益因子的标称值是1，并且下图示出当增益因子被设置成它的标称值时所收集的样本信号：

类似于设备上的异常检测，这里也可以应用相似的过程。数据长度被取为0.8秒，这相当于80个数据点。区域化所基于的矢量是包括由Accelerator 2512和n_Engine 2514所连接的两个输入序列以及输出al_ThrottleECU 2511的初始条件的矢量。在所述特征矢量的适当的归一化之后，基于训练数据创建了SOM，以对系统动态行为进行区域化。利用TFA和PCA针对每个区域建立正常的统计分布。

当所述训练完成之后，所述控制器检测器已经对测试数据进行了测试。下图示出来自与所述控制器相关的异常检测器的结果：

可以观察到，当所述控制器的增益因子从它的标称值1减小到0.65时，所述置信值降低，然而所述方差增大。

各个异常检测器能够感测系统参数的逐步退化。如果结合来自不同异常检测器的结果，也能定位异常。为了示范这种能力，讨论了两种情况。在第一种情况中，使为设备的参数的硬度K在大约700秒内从标称值40逐步减小到24。包括所述控制器和所述设备的参数的其它参数被保持在它们的标称值。在第二种情况中，干乱被引入到为所述控制器的参数的增益因子中，并且也使所述增益因子在大约700秒内从标称值1指数地减小到0.6。下图示出在所述两种情况中随时间变化的参数：

以前讨论的两种异常检测器随后对标准驱动简档进行测试，所述标准驱动简档未被用于训练。所述第一种情况对第一驱动简档ECE2进行测试，并且所述第二种情况对第二驱动简档FTP75进行测试。这两种特定的驱动简档相当于ETAS的产品LABCAR中的驱动简档。下图示出异常检测结果：

为了滤除噪声，指数加权移动均值(EWMA)算子被应用于所述置信值。横越窗口的直线是基于在训练数据集上观察到的置信值的统计所计算出来的控制下限。

可以看出，对于第一种情况来说，来自所述控制器的置信值始终都是高的，但是来自所述设备上的异常检测器的置信值逐步地减小，并且最后从控制极限离开。这表明在所述设备中出现了异常，但是所述控制器仍然正常运行。对于第二种情况来说，由于干扰被引入到所述控制器参数中，来自所述控制器异常检测器的置信值减小并离开所述控制极限，而来自所述设备异常检测器的置信值保持在所述控制极限之内。因此，能够容易地确定所述异常在所述控制器、所述设备、或两者中的位置。如所示范的使设备和控制器异常去耦的能力对于找到所述异常的位置来说是重要的。

图27是异常检测系统2700的示例流程图。操作流开始于起始点2702。分区操作2704将运行时环境分区为至少一个操作区域。所述分区可被称为区域化。学习操作2706学习操作区域内的正常行为。所述学习可被称为训练。监控操作2708监控当前行为。比较操作2710将正常行为与当前操作行为进行比较。检测操作2712在当前操作行为与正常操作行为之间存在偏离时检测出异常。追溯操作2714通过链接将异常追溯回集成开发环境。识别操作2716基于异常的追溯识别集成开发环境中的异常。

如在此讨论的那样，披露了一种新颖的异常检测方案，其能够检测受控系统的性能的逐步退化，并且能够定位所述异常。不同于传统的基于模型的缺陷诊断，所提出的方法不需要系统动态的详细知识。正常输入和输出信号的存在是所提出的方法的唯一假定。

所述方法能够通过基于SOM的区域化以及基于TFA的性能评估利用正常输入输出信号在统计上建立输入-输出关系，而不用顾及系统的类型是线性的还是非线性的。模型建立过程是非常高效的。这显著地减少所述诊断系统的开发时间。

所披露的方法已经在汽油发动机车辆模型的子系统上进行了论证。已经示出所述异常检测器能够检测不同种类的系统参数漂移。此外，这两种异常检测器能够将所述设备和控制器异常去耦。基于所述异常检测器的结果，能够定位所述设备、控制器、或两者中的异常。

本领域的技术人员将认识到在此描述的系统能够利用任意数量的软件配置、网络配置、硬件配置等来实现。

在此所示出的不同实施例的逻辑操作被实现为：(1)计算机实现的步骤序列或运行在计算系统上的程序模块；(2)计算系统内的互连的逻辑电路或电路模块。所述实现是取决于实现本发明的计算系统的性能需求的选择问题。相应地，组成在此描述的本发明实施例的逻辑操作分别被称为操作、步骤、引擎、或模块。

上面描述的不同实施例仅以说明性的方式提出，但是不应将其解释为限制本发明。本领域的技术人员会容易地认识到，无需遵循在此图解和描述的示例实施例和应用，并且在不背离由在下面的权利要求中所阐述的本发明的真正精神和范围的情况下，可以对本发明做出各种各样的修改和变化。

Claims

1.一种用于检测异常的系统，所述系统包括：

产生输出的第一硬件系统；

具有到集成开发环境的双向链接的第一运行时环境，所述第一运行时环境包括：

第一控制系统，通过给所述硬件系统的控制输入来控制所述硬件系统；

第一诊断代理，用于检测所述硬件系统中的异常；以及

第二诊断代理，用于检测所述控制系统中的异常；

其中所述第一和第二诊断代理能够通过在所述第一运行时环境内比较当前操作行为与正常操作行为来检测系统的性能的逐步退化从而检测出异常以及通过所述双向链接将所述异常追溯回集成开发环境。

2.根据权利要求1所述的系统，其中：

所述集成开发环境包括运行在所述集成开发环境内的软件和硬件开发工具的集合，所述软件和硬件开发工具使得能够将第一和第二诊断代理部署到所述运行时环境中。

3.根据权利要求1所述的系统，进一步包括：

产生输出的第二硬件系统；

具有到所述集成开发环境的双向链接的第二运行时环境，所述第二运行时环境包括：

第二控制系统，通过给所述硬件系统的控制输入来控制所述硬件系统；

第三诊断代理，用于检测所述硬件系统中的异常；以及

第四诊断代理，用于检测所述控制系统中的异常；

其中所述第三和第四诊断代理能够通过在所述第二运行时环境内比较当前操作行为与正常操作行为来检测系统的性能的逐步退化从而检测出异常以及通过所述双向链接将所述异常追溯回所述集成开发环境。

4.根据权利要求1所述的系统，其中：

所述双向链接包括开发运行时开发链接，该开发运行时开发链接与数据库和消息传递的组合相关联，以便包含由所述集成开发环境产生的配置数据以及将所述配置数据传递到所述第一运行时环境，以便将所述第一和第二诊断代理部署在所述第一运行时环境中。

5.根据权利要求4所述的系统，其中：

所述双向链接从所述第一运行时环境接收异常，并且将所述异常传递到所述集成开发环境。

6.根据权利要求1所述的系统，其中：

所述第一诊断代理包括多个第一诊断代理；并且

所述第二诊断代理包括多个第二诊断代理。

7.根据权利要求1所述的系统，其中：

所述第一运行时环境包括多个运行时环境。

8.一种用于在包括通过链接双向连接的集成开发环境和运行时环境的系统中检测异常的方法，所述方法包含：

将所述运行时环境分区为至少一个操作区域；

学习所述操作区域内的正常操作行为；

在系统运行期间，监控所述操作区域内的当前操作行为；

比较当前操作行为与正常操作行为；

在当前操作行为与正常操作行为之间存在偏离时检测出异常；

通过所述链接将所述异常追溯回所述集成开发环境；以及

基于所述异常的追溯，识别出所述集成开发环境中的异常。

9.根据权利要求8所述的方法，其中：

对系统进行分区包括利用自组织映射将所述系统分区为至少一个操作区域。

10.根据权利要求9所述的方法，其中：

对系统进行分区包括利用自组织映射将所述系统自动分区为至少一个操作区域。

11.根据权利要求8所述的方法，其中：

检测异常包括利用时间-频率分析来检测异常。

12.根据权利要求11所述的方法，其中：

检测异常包括利用识别与所述正常操作行为的统计偏离的时间-频率分析扩展来以高统计精度检测异常。

13.根据权利要求8所述的方法，其中：

对系统进行分区包括被称为区域化的将所述系统分区为至少一个操作区域。

14.根据权利要求8所述的方法，其中：

学习正常操作行为包括被称为训练的学习所述操作区域内的正常操作行为。

15.根据权利要求8所述的方法，进一步包括：

识别所述集成开发环境中的操作区域。

16.根据权利要求8所述的方法，其中：

对系统进行分区包括将所述系统分区为至少一个能够由单个异常检测器观测的操作区域。

17.根据权利要求8所述的方法，其中：

基于所述异常的追溯识别所述集成开发环境中的异常包括基于所述异常的追溯识别所述集成开发环境中的异常的根本原因。

18.一种用于在包括通过链接双向连接的集成开发环境和运行时环境的系统中检测异常的系统，所述系统包含：

将所述运行时环境分区为至少一个操作区域的分区模块；

学习所述操作区域内的正常操作行为的学习模块；

在系统运行期间监控所述操作区域内的当前操作行为的监控模块；

比较当前操作行为与正常操作行为的比较模块；

在当前操作行为与正常操作行为之间存在偏离时检测出异常的检测模块；

通过所述链接将所述异常追溯回所述集成开发环境的追溯模块；以及

基于所述异常的追溯识别出所述集成开发环境中的异常的识别模块。

19.根据权利要求18所述的系统，其中：

所述分区模块使用自组织映射。

20.根据权利要求18所述的系统，其中：

所述检测模块使用时间-频率分析。

21.根据权利要求18所述的系统，其中：

所述分区模块将所述系统分区为至少一个能够由单个异常检测器观测的操作区域。

22.一种计算系统可读的计算机程序产品，该计算机程序产品对指令进行编码，该指令在包括通过链接双向连接的集成开发环境和运行时环境系统中诊断模型错误，计算机进程包括：

将所述运行时环境分区为至少一个操作区域；

学习所述操作区域内的正常操作行为；

在系统运行期间监控所述操作区域内的当前操作行为；

比较当前操作行为与正常操作行为；

通过所述链接将所述异常追溯回所述集成开发环境；以及

基于所述异常的追溯识别出所述集成开发环境中的异常。

23.根据权利要求22所述的计算机程序产品，其中：

24.根据权利要求23所述的计算机程序产品，其中：

25.根据权利要求22所述的计算机程序产品，其中：

检测异常包括利用时间-频率分析来检测异常。

26.根据权利要求25所述的计算机程序产品，其中：

27.根据权利要求22所述的计算机程序产品，其中：

28.根据权利要求22所述的计算机程序产品，其中：

29.根据权利要求22所述的计算机程序产品，进一步包括：

识别所述集成开发环境中的操作区域。

30.根据权利要求22所述的计算机程序产品，其中：

31.根据权利要求22所述的计算机程序产品，其中：

基于所述异常的追溯识别出所述集成开发环境中的异常包括基于所述异常的追溯识别出所述集成开发环境中的异常的根本原因。