CN101416164A

CN101416164A - 用于基于学习模型的生命周期诊断的方法和系统

Info

Publication number: CN101416164A
Application number: CNA2004800316954A
Authority: CN
Inventors: W·L·米勒
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2003-10-28
Filing date: 2004-10-27
Publication date: 2009-04-22
Also published as: US20050091642A1; WO2005045626A3; WO2005045626A2; EP1716467A2

Abstract

一种用于基于学习模型的生命周期诊断的系统包括集成开发环境、运行时环境和双向链路。所述集成开发环境包括内部链接的软件工具。所述运行时环境包括内部链接的、检测故障的代理。所述双向链路将集成开发环境和运行时环境链接在一起。在该系统中，在运行时环境中检测到的故障能够被追溯到集成开发环境以确定模型错误。在包括双向链接的集成开发环境和运行时环境的软件环境中，一种诊断模型错误的方法包括：检测运行时环境内的故障；将该故障追溯到集成开发环境；以及根据故障的追踪来识别集成开发环境中的模型错误。

Description

用于基于学习模型的生命周期诊断的方法和系统

本申请是以美国国营公司ETAS的名义作为PCT国际专利申请提交的，其中申请人对应于除美国以外的所有指定国，而美国公民WilliamL.Miller仅对应于美国这一指定国，并且本申请要求了2003年10月28日提交的序列号为10/696,426的美国申请的优先权。

技术领域

本发明涉及软件和系统，更特别地，本发明涉及用于集成开发和运行时环境的多级、多体系(regime)开发工具和运行时软件代理。

背景技术

在目前的产品开发范例中，在开发期间主要设计、测试和实施产品的质量、产品的制造及其服务。产品、产品的制造或其服务中的错误是在开发期间加以识别和校正的。一旦产品被发布，就难以发现其余的质量问题。

目前，一种称为六西格玛(sixsigma)的方法论尝试主要在开发和制造过程中定位产品中的根本原因和故障。这些根本原因活动是人员集约的，这除了诸如工程学的其它学科以外还包含“黑带”及其它质量专家。软件是将焦点集中在具备知识的人员、工具、技术和良好过程(模型驱动的软件工程)进行开发的，以便在开发期间发现问题。因为软件以此为焦点来开发并且查找根本原因是人员集约的，所以期望得到改善。

发明内容

根据本发明，上述及其它问题是通过如下方式来解决的：

在本发明的一个方面中，公开了一种用于基于学习模型的生命周期诊断的系统。所述系统包括：集成开发环境、运行时环境和双向链路。所述集成开发环境包括内部链接的软件工具。所述运行时环境包括内部链接的检测故障的代理。所述双向链路将集成开发环境和运行时环境链接在一起。在该系统中，运行时环境中检测到的故障能够被追溯到集成开发环境以确定模型错误。

在本发明的另一个方面中，公开了一种诊断软件环境中的模型错误的方法。所述软件环境包括双向链接的集成开发环境和运行时环境。所述方法包括：检测运行时环境内的故障；将该故障追溯到集成开发环境；以及根据故障的追踪来识别集成开发环境中的模型错误。

在本发明的另一个方面中，公开了一种用于诊断软件环境中的模型错误的计算系统可读的和编码计算机过程的指令的计算机程序产品，所述软件环境包括双向链接的集成开发环境和运行时环境。所述计算机过程包括检测运行时环境内的故障；将故障追溯到集成开发环境；以及根据故障的追踪来识别集成开发环境中的模型错误。

在本发明的另一个方面中，公开了一种用于车辆的基于学习模型的生命周期诊断的系统。所述系统包括：集成开发环境、运行时开发和双向链路。所述集成开发环境包括链接在一起的需求管理工具、设计工具和部署工具。所述运行时环境包括链接在一起的检测故障的应用程序、中介(broker)和代理。所述双向链路将集成开发环境和运行时环境链接在一起。在该系统中，在运行时环境中检测到的故障被追溯到集成开发环境以确定模型错误。

本发明可被实施为计算机过程；作为可以发布的计算系统；或者作为诸如计算机程序产品之类的一件产品。所述计算机程序产品可以是计算机系统可读的和编码用于执行计算机过程的计算机程序指令的计算机存储介质。所述计算机程序产品还可以是在计算系统可读的和编码用于执行计算机过程的计算机程序指令的载体上传播的信号。

对本发明的更完整认识及其范围可以从简述如下的附图中、从本发明的当前优选实施例的下列详细说明中以及从所附的权利要求中获得。

附图简述

现在参照附图，相同的参考编号始终表示相应的部件：

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

图2是可被用来实施本公开内容的各方面的计算系统的示意图；

图3是根据本公开内容的示例性实施例的、产品开发的框图；

图4是根据本公开内容的示例性实施例的、与棘手的(wicked)问题相关的需求的示意图；

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

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

图7根据本公开内容的示例性实施例举例说明了实例图形用户界面；

图8是根据本公开内容的示例性实施例举例说明分布式系统的示意图；

图9是根据本公开内容的示例性实施例举例说明车辆产品开发的过程图；

图10是根据本公开内容的示例性实施例举例说明螺旋生命周期过程的过程图；

图11是根据本公开内容的示例性实施例举例说明螺旋生命周期过程的过程图；

图12是根据本公开内容的示例性实施例举例说明车辆开发阶段的过程图；

图13是根据本公开内容的示例性实施例举例说明生命周期方法如何通过需求进展的过程图；

图14是根据本公开内容的示例性实施例举例说明生命周期方法如何应用螺旋子过程的过程图；

图15是根据本公开内容的示例性实施例举例说明如何应用生命周期方法的过程图；

图16是根据本公开内容的示例性实施例举例说明生命周期方法如何进展的过程图；

图17是根据本公开内容的示例性实施例举例说明生命周期方法如何应用螺旋子过程的过程图；

图18是根据本公开内容的示例性实施例举例说明如何在螺旋子过程中应用生命周期方法的过程图；

图19是根据本公开内容的示例性实施例的系统图；以及

图20根据本公开内容的示例性实施例举例说明生命周期方法如何将各级链接在一起。

图21是根据本公开内容的示例性实施例表示基于学习模型的诊断系统的逻辑操作的流程图。

详细说明

在本发明优选实施例的以下描述中，参考形成为本发明一部分的附图，并且其中通过例示其中可以实践本发明的具体实施例的方式来示出。应该理解的是：可以利用其它实施例，并且在不脱离本发明范围的情况下可以作出改变。

本公开内容描述了用于基于学习模型的生命周期软件和系统的方法和系统。更特别地，所述软件和系统包括链接在一起的集成开发环境(IDE)和运行时环境(RTE)。所述IDE包含链接在IDE内且链接到RTE的一组开发工具。所述RTE包括链接在RTE内且链接到IDE的多个诊断代理。由此，所述开发工具和诊断代理相互进行通信。

现在参照图1，举例说明了基于学习模型的生命周期系统100的实例示意图。IDE 105包括链接在IDE 105内的一组软件工具。RTE 110包括链接在RTE 110内的另一组软件代理。所述IDE 105和RTE 110是经由链路115链接在一起的。

图2和下列讨论意在提供其中可以实施本发明的适当的计算环境的简要的、一般性描述。尽管不需要，但是还是在一般的计算机可执行指令的上下文中描述了本发明，这些指令诸如由计算系统执行的程序模块。总体上讲，程序模块包括执行特定任务或实施特定抽象数据类型的例程、程序、对象、组件、数据结构等等。

本领域的技术人员将会认识到：本发明可以利用其它计算机系统配置来实践，该其它计算机系统配置包括：手持设备、掌上设备、多处理器系统、基于微处理器的或可编程的消费电子设备、网络个人计算机、微型计算机、大型计算机等等。本发明也可以在分布式计算环境中实践，在该分布式计算环境中任务是由经由通信网络链接的远程处理设备来执行的。在分布式计算环境中，程序模块可以位于本地和远程存储器存储设备中。

现在参照图2，用于实施本发明的实施例的示例性环境包括计算系统200形式的通用计算设备，其包括至少一个处理系统202。各种处理单元可从各种制造商(例如，英特尔或先进微电子器件公司(AdvancedMicro Devices))那里购买到。所述计算系统200还包括：系统存储器204，和将包括系统存储器204的各种系统组件耦合到处理单元202的系统总线206。所述系统总线206可以是几种类型的总线结构中的任何一种，这些总线结构包括：存储器总线或存储器控制器；外围总线；和使用各种总线架构中任何一种的本地总线。

优选地，所述系统存储器204包括只读存储器(ROM)208和随机存取存储器(RAM)210。基本输入/输出系统212(BIOS)通常被存储在ROM 208中，该基本输入/输出系统212(BIOS)包含帮助在计算系统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还包括用于激活麦克风并将声音输入传送至存储器204的录音按钮261。

诸如计算系统200之类的计算设备通常包括至少某种形式的计算机可读介质。计算机可读介质可以是任何能由计算系统200进行存取的可用介质。作为举例而非限制，计算机可读介质可以包括计算机存储介质和通信介质。

计算机存储介质包括以用于信息存储的任何方法或技术实施的易失性和非易失性的、可移动和不可移动的介质，所述信息诸如是计算机可读指令、数据结构、程序模块或其它数据。计算机存储介质包括但不限于：RAM、ROM、EEPROM、快速存储器或其它存储技术、CD-ROM、数字化视频光盘(DVD)或其它光存储器、磁带盒、磁带、磁盘存储器或其它磁存储设备，或是能被用来存储所期望的信息而且能由计算系统200进行存取的任何其它介质。

通信介质典型地包含有：计算机可读指令、数据结构、程序模块或所调制的数据信号中的其它数据，诸如载波或其它传送机制并且包括任何信息传送介质。术语“所调制的数据信号”意指具有一个或多个其特征集或按这样一种编码信号中的信息的方式变化的信号。作为举例而非限制，通信介质包括：诸如有线网络或直接有线连接之类的有线介质；还包括诸如声音、RF、红外线及其它无线介质之类的无线介质。任何上述的组合也应该被包括在计算机可读介质的范围内。计算机可读介质也可被称为计算机程序产品。

图3是举例说明开发系统300的框图，该开发系统300可包括软件和开发工具。所述开发系统300在产品开发中包括三个基本类型的组件，所述产品例如是车辆。块310是需求组件。产品和系统开发中的第一步使用了该需求组件。所述需求组件定义将包括什么产品和系统。块320是设计组件。在确定产品和系统的需求之后，将产品和系统设计成符合那些需求。块330是实施组件。在设计产品和系统之后，根据设计组件来制造产品和系统并交付使用。所述系统还可以包括用于供应和服务链整合的企业应用程序。另外，所述系统能够包括运行时应用程序服务，该运行时应用程序服务包括电信和操作基础设施和车辆。

使用车辆作为例子，汽车制造商决定利用用于基于学习模型的生命周期诊断的系统来制造新型X汽车。在块310，确定对于X汽车和系统的需求。例如，所述X汽车应该是具备某一有效载荷、加速度的轿车并且不应该超出$20000。所述系统应该降低提保维修(warrantyrepair)成本并提高客户满意度。

在块320，根据那些需求来设计所述X汽车和系统。将汽车的框架和悬架设计成能承载所需的有效载荷，根据车辆总重和加速需求来设计或选择动力系，并且将X汽车的其余部分的成本设计成不超过$20000。例如，已知X汽车不应该超出$20000，工程师则可能决定选择仅仅满足加速需求的引擎而不会选择将大大超出加速需求的引擎。所述系统应该使用具有嵌入式网络平台的网络服务加以设计，以运行在由服务器、远程信息处理和嵌入在车辆中的电子设备组成的三层体系架构上。所述系统可以具有分布式数据库，以使服务器能贯穿供应和服务链而被定位。所述系统可以包括开发、制造和服务工具。

在块330，根据所述设计，实施、也就是制造并交付使用了X汽车和系统。在供应和服务链中，实施贯穿三层体系架构来部署软件和硬件。

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

在需求步骤中，存在两类确定待分析的产品和系统的类型的知识问题，继而是开发、制造和服务所需要的工具和过程。这两类问题包括“缓和的(tame)”和“棘手的(wicked)”问题。多数问题是缓和的并且能够利用阶段-门户(stage-gate)、线性过程和基于信息的工具来解决。开发系统的需求以管理棘手的问题需要螺旋过程和基于知识的工具。

棘手的问题包括一组链接的问题和约束条件，并且并不具有明确的问题本身的陈述。所述问题(及因此用于设计解决方案的需求)直到已经开发出表示解决方案候选者的迭代原型之前都无法被充分地理解。在初级整体开发过程内，所述过程是线性的，需要迭代原型的次级螺旋过程。所述螺旋过程包含当正在开发另一部分的同时每次“转出(rolling out)”一部分软件。所述软件工程协会已经认识到，螺旋过程对快速的、有效的开发是必不可少的。

棘手的问题的例子是汽车的设计和对汽车的诊断。在1970年，Horst Rittel引入了“棘手的(wicked)”这个专业词汇。Rittel发明了一种称为基于问题的信息系统(IBIS)的技术来帮助解决这种新类型的问题。棘手的问题看起来与不良结构的问题非常类似，但是有许多风险承担者，他们对这种问题的观点可能不同。棘手的问题必须利用螺旋的、迭代的过程来分析，并且诸如与所述问题相关联的需求之类的观点必须被链接在新的范例400中，如图4中举例说明的那样。

参照图4，三个关键的IBIS实体是：(1)问题402、403、404(或疑问)，(2)位置405、406、408(或提供可能的解决方案或所述问题的解释的观点)，以及(3)论证410、412(或正面的论证和反面的论证)。所有三个实体都能够通过关系加以链接，该关系诸如是支持(supports)、反对(objects-to)、由...提出(is-suggested-by)、响应于(responds to)、一般化(generalizes)、特殊化(specializes)、替换(replaces)及其它。IBIS的可视化变为图表或网络。IBIS在设计与论证或者形成知识管理的核心的所表达的观点对话之间架桥。

IBIS是具有语法(或论证映射的形式)的图形语言。应用IBIS需要与实验设计(DOE)相似的技能。Jeffrey Conklin(http://cognexus.org/id17.htm)最早提出了IBIS结构的图形超文本视图的应用，其中引入了图形IBIS或gIBIS。IBIS的强度(根据Conklin)源自于三个属性：(1)IBIS将复杂的思维映射到分析结构图中，(2)IBIS面临着形成知识基础的问题，和(3)IBIS图比其它信息形式更容易被理解。

Compsim LLC已经按几种方式扩展了IBIS。在其IBIS工具体系架构中，观点能够以文本概括或节点的树型结构的形式来表示。给定级别的观点能够具有优先级和权重，以改变观点显示的排序。优先级能够容易地以各种图形方式来编辑。唯一的决策机制以用于支持否定论证的相对加减法来摹拟人类思考。捕获IBIS逻辑作为XML定义并且将其用于建立基于知识的代理网络的链接式网络。Compsim称这个代理结构知识为增强型电子逻辑(KEEL)。所述代理执行扩展形式的IBIS逻辑。

包含IBIS的当前字段(field)被称作计算机辅助的论证可视化(CSAV，computer-supported argument visualization)。应用CSAV的相关字段是帮助产生(spawn)因特网的计算机辅助协作工作(CSCW，computer-supported cooperative work)和计算机居间通信(CMC，computer-mediated communication)。CMC工具包括微软的NetMeeting^TM产品。

论证可视化是用于定义需求管理中所发现的复杂关系的关键技术，需求管理是知识管理(KM)的子集。KM的原理之一是在构造论者学习理论中被发现的，该构造论者学习理论需要通过合作对话来协商知识的构造。所述协商涉及观点的对比测验。具有观点可视化的相应对话创建隐式知识，该隐式知识包括与直接被链接到信息的知识的显式部分相反的最大一部分的知识。隐式知识对共享理解(sharedunderstanding)而言是必不可少的。

IBIS是基于知识的技术。用于需求管理的IBIS工具、诸如Compenium^TM或QuestMap^TM(GDSS公司的商标)明显不同于用于RM的面向对象的(OO)构架工具、诸如Telelogics的Doors^TM或者IBM的Requisite-Pro^TM。无法容易地定义棘手的问题，以致所有风险承担者对待解决的难题或问题意见达成一致。存在无法容易地利用RM工具来以OO构架表达的权衡。IBIS允许二元的、所位于的情况来定义需求。IBIS允许需求被模拟。IBIS能够感知那些情况并确定哪个需求集合是适当的或者所述需求甚至是否充分地应用于所述情况。

总而言之，目前的RM工具有局限性。OORM工具允许在开发期间而非在制造或服务部署阶段期间的需求、设计和实施之间的可溯性。OO RM工具不是基于知识的并且无法容易地处理不良构造的棘手问题，所述棘手问题具有与表达为正面和反面论证的那些视图的不同加权的优先级相冲突的多个风险承担者视图。IBI SRM工具克服了那些局限性中的大部分但是并没有开发出用于系统设计的可溯需求。

OO RM和IBIS RM工具两者都认识到如单独用文本表达的观点之间的关系在没有诸如带有相关等级结构的概括之类的附加结构的情况下是不清楚的。诸如那些可能利用超文本技术所产生的网络结构能够被追溯到Vannevar Bush和他的1945年的文章“As We May Think”。在1962年，Douglas Englebart在其来自于斯坦福研究机构的报告“Augmenting Human Intellect：A Conceptual Framework”中定义了一种用于利用工具来认知论证的构架。Englebart研发工作的结果是现代窗口、图标、鼠标、和指针(WIMPT)图形用户界面(GUI)的开发以及基于超文本的工具的早期实施。

OO的往返工程或者模型驱动的软件开发是实施方案的源代码，该实施方案的源代码可追溯到设计与需求的元素。该往返作为源代码在需求、设计与实施之间并然后返回到设计和需求。由于往返工程目前仅仅在开发期间出现并且仅仅出现在IDE的某些段内，所以在开发之后呈现在RTE中的模型错误无法被追溯到需求、设计或实施中的根本原因。分段的IDE可以包括四个四分之一圆周。这些四分之一圆周包含用于下列情况的方法和工具：(1)系统中的企业应用程序，(2)车辆的嵌入式软件，(3)车辆的远程信息处理，和(4)车辆的服务系统。

时常，利用统一建模语言(UML)来定义OO模型。UML是第三代OO图形建模语言。如在使用案例中所定义的那样，所述系统模型具有与称作施动者的外部用户相交互的结构、行为和功能方面。使用案例是已命名的系统性能。系统需求典型地落入两类：功能需求和非功能或服务质量(QoS)需求。

功能意指所述系统应该做什么。QoS意指做得多好或功能的性能属性。在公共用途中，功能能够暗指功能性和性能两者。所述结构方面定义了在运行时可能存在的对象和对象关系。子系统、包和组件也定义了可选的结构方面。所述行为方面定义了结构元素如何在运行时系统中工作。UML提供了状态图(有限状态机的形式表达法)和活动图，以详细说明动作和所允许的排序。活动图的共用说明了计算算法。结构元素的集合像交互那样随着时间一起工作。交互是按顺序定义的或者是协作图。

典型地，捕获包括功能和QoS方面的系统的需求作为以下两种方式中的任意一种：(1)模型是具有在状态图和交互图中所定义的详细需求的使用案例，或(2)像带有或没有正式图、诸如顺序图的文本那样的说明书，其试图定义所有可能的系统行为的情况。

往返工程通过OO设计将OO需求追踪到包含OO软件源代码的OO实施中。这个往返仅仅出现在IDE的某些段中，所述IDE的某些段是OO IDE段，并且仅仅在开发期间出现。目前，在开发、制造和服务期间，在RTE和IDE之间没有往返可溯性。往返工程已被扩展来使用元模型而不需要令人厌恶的源代码标记，但是被扩展的往返工程仍然仅仅在开发期间出现在IDE的某些段内。

基于模型的诊断是用于故障隔离的现有技术方法，该故障隔离是用于识别未正确地遵照被规定为车辆和系统的实施模型的部分的工作参数来工作的车辆和系统的一个或多个故障组件的过程。基于模型的诊断遭受假定模型无错误且准确地表示系统的所有工作情况的限制。系统的工作情况包含所有预期的故障。

如果在运行时可以得到来自车辆的足够量的可观测信息，则基于模型的诊断就能够确定先前已知的根本原因和扩展模型所预测的预期故障模式，所述扩展模型包括正常模式和故障模式。所述扩展模型被用来模拟并记录因所有可能的单个组件故障而引起的行为，继而是多个组件故障的组合。当观测到故障行为时，可以执行预定实验的顺序，以确定根本原因。

车辆和系统的需求或设计和实施模型中的故障主要是在开发之后被用户检测到的，所述用户可能会抱怨并且服务技术人员分析他们的投诉，继而可能由工程师来分析他们的投诉。导致投诉的情况常常是不容易被识别出来的并且是可再现的。故障隔离或根本原因确定的过程通常从检测非正常系统行为开始并且尝试识别该一个或多个损坏的和不正确工作的组件。这些组件执行系统中的功能的某个集合。所述组件时常被设计成为可现场更换的、可能包含软件的硬件单元。然而，在目前实践中所假定的故障模型考虑到了可更换组件的功能故障模式并且并没有确定该一个或多个组件内部的故障是硬件故障还是软件故障。如果该故障是软件故障，那么所述故障就是在需求、设计或实施级上的模型故障。更换该一个或多个硬件组件将不能修复所述难题。

在一个实例实施例中，考虑一种检测车辆功能子系统中的生命周期故障的改进方法和系统，所述故障是由硬件故障或者需求、设计或实施中的模型错误而引起的并且将所述故障追溯到模型中的根本原因。对于追踪，所述方法使用了用于生命周期往返工程的新性能，该性能将RTE中的诊断代理与IDE中的二元模型相链接，用于管理车辆功能的开发和维护以及相应的诊断。IDE中的二元模型是由所链接的二元工具来管理的，所述工具开发了螺旋开发“V”过程(稍后将作更详细地描述)的每一级上的功能和相应的诊断：需求、设计和实施。将IDE和RTE链接在一起的生命周期诊断方法能够在车辆的开发、制造和服务RTE期间被应用。

参照图5和6，举例说明了基于学习模型的生命周期诊断系统499。优选地，所述系统499包括由DRD链路599链接在一起的IDE 500和RTE 600。图5是根据一个实例实施例的、用于开发IDE 500中的车辆功能和相应诊断以及RTE 600中的诊断部署以维修车辆的生命周期诊断方法的系统图。该图举例说明了生命周期方法如何在IDE 500中以链接将开发工具链接在一起的。生命周期方法中的IDE 500包含开发工具和开发车辆功能和相应诊断应用程序的过程，所述诊断应用程序包括一组用于在RTE 600中部署的被集成且被链接的诊断代理。所述IDE 500和RTE 600是通过DRD链路599以及相应的过程而链接起来的。所述DRD 599能够包括数据库，该数据库可以是分布式数据库。

图6是根据一个实例实施例的、用于IDE 500中的诊断开发和RTE600中的诊断部署以维修车辆的生命周期诊断方法的系统图。该图举例说明了生命周期方法如何在RTE 600中以链接将诊断代理链接在一起的。生命周期方法中的RTE 600包含并操作被部署为三级系统的诊断应用程序，所述三级系统包括：运行在服务器上的诊断代理、TCU(或插入车辆中的等效模块)、和ECU。制造服务工具连接到车辆并且是RTE 600的部分。RTE 600经由DRD链路599以及相应的过程而被链接回到IDE 500。

如图7中所示，诸如Compsim KEEL工具包之类的IDE工具能够由在DRD链路499(图5)中所返回的数据来驱动，以模拟和测试设计模型并且分析故障模式。下面所示的数据是由IDE 500(图5)以XML定义的输入方案的例子；所述方案被存储在DRD链路599中：

-<Schema name=＂KEELDataSchemaxml＂xmlns=＂um:schemas-

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

com:datatypes＂>

-<ElenentType name＝＂InDat＂content＝＂eltOnly＂model＝＂closed＂>

</ElementType>

<ElementType name＝＂ProjectTitle＂content＝＂textOnly＂

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

-<ElementType name＝＂Report＂content＝＂eltOnly＂

model＝＂closed＂>

</ElementType>

</Schema>

所述DRD链路599消除了对RTE代理600的需要，以知道如何与IDE 500中的工具进行通信。所述系统499仅仅使用DRD链路599中的信息在IDE 500和RTE 600之间创建正确的链接。从RTE 600返回到IDE 500的数据的例子被显示如下：

<？xnl version＝＂1.0＂？>

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

-<InDat>

</InDat>

-<InDat>

</InDat>

-<InDat>

</InDat>

-<InDat>

</InDat>

-<InDat>

</InDat>

-<InDat>

</Report>

现在返回到图5，优选地，所述IDE 500具有带相应工具和过程的系统499的用户的三级开发活动。这三级是需求管理、设计和实施。所述系统499在IDE 500中的每一级处创建用于功能和诊断的所链接的二元工具对。

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

所述IDE 500包括：第一RM 502、第二RM 504、第一设计工具506、第二设计工具508、第三设计工具510、第一部署工具512、第二部署工具514和第三部署工具516。优选地，所述第一RM 502被实施为OO RM工具，而所述第二RM 504被实施为IBI SRM工具。所述第一设计工具506被实施为OO模型驱动的功能设计工具、诸如IBM/Rational Rose^TM、iLogix的Rhapsody^TM、Math Works的Simulink^TM或ETAS的ASCET/SD^TM。

所述第二设计工具508被实施为基于知识的诊断设计工具。所述第三设计工具510被实施为基于模型的诊断设计工具。所述第二设计工具508和第三设计工具510包括诊断构造器工具组，该诊断构造器工具组既包含基于知识的诊断设计工具又包含基于模型的诊断设计工具。这些工具使系统499的用户能为相应设计的车辆功能开发运行时诊断代理。所述诊断代理意图在RTE 600(图6)的三级上运行。诊断构造器组为每个诊断代理规定RTE 600的目标级并在RTE 600中的代理之间构造图6中所示的链路。基于知识的代理开发工具的例子是Compsim的KEEL^TM。基于模型的代理开发工具的例子是R.O.S.E.的Rodon^TM。

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

所述第一RM 502经由链路518被链接到第二RM 504。所述链路518是本领域中所公知的任何标准通信链路。所述链路518是双向的集成链路，该双向的集成链路能捕获第一RM 502中所捕获的需求背后的知识、假定和决策逻辑。优选地，所述系统499通过将第一RM 502中的对象的唯一XML功能标识符描述符(FID-RM)传递到第二RM 504以及通过利用XML诊断标识符描述符(DID-RM)构造数据关系来实施链路518。链路518的二元关系被存储在DRD链路599中。通过将第二RM 504开窗口(windowing)到第一RM 502的图形用户界面中，所述系统499使用户能定义正被捕获为第一RM 502中的对象(诸如使用案例)的需求背后的决策逻辑。与第一RM 502中的对象相对应的第二RM 504中的逻辑被定义为唯一的XML诊断标识符描述符(DID)。

所述第一设计工具506经由链路520被链接到第二和第三设计工具508、510。链路520双向传递用于设计的唯一XML定义的功能标识符描述符(-D)和用于设计的诊断标识符描述符(-D)并且在设计级上集成独立工具的图形用户界面。

所述第一部署工具512(或功能模块)经由链路522被链接到第二和第三部署工具514、516(或诊断代理)。链路522双向传递用于实施的唯一XML定义的功能标识符描述符(-I)和诊断标识符描述符(-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集成基于模型的诊断设计工具，诸如利用诸如ASCET/SD^TM之类的工具来生成源代码的R.O.S.E的Rodon^TM，以生成用于在RTE 600(图6)上实施的实时操作系统上的可执行代码。

参照图6，所述RTE 600具有三级软件和硬件。利用IDE 500中的工具(DRD链路599)和过程，所述系统499允许将诊断应用程序构造为在三级上运行的所链接的诊断代理集合。一些代理能够利用OSGi^TM被下载到第二级上。

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

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

所述IDE 500和RTE 600经由链路599被链接在一起。链路599是开发、运行时、开发(DRD，Development，Run-time，Development)链路。优选地，所述DRD链路599是使用包含分布式数据库和软件进程间通信(IPC)机制的组合的电信和操作基础设施(TOI，telecommunications and operations infrastructure)来实施的。在DRD链路599中，通过数据库或IPC机制发送的信息是按XML方案定义的并且包含IDB 500和RTE 600数据这两者。所述XML方案能够以消息方式发送或者可选地被用于配置分布式数据库。

在开发期间，使用IDB 500中的新诊断工具来指导用户跟随螺旋“V”过程，“向下”和“向上”所述“V”，以在需求、设计和实施级上的利用功能标识符描述符(FID)唯一标识的功能与利用诊断标识符描述符(DID)唯一标识的相应诊断之间构造IDE模型链接(正如下面更详细地描述的那样)。带有FID和DID的IDE二元(功能-诊断)模型链接被存储在DRD链路599数据库中。

因此，由于所述方法在开发期间经迭代原型循环跟随螺旋“V”过程，所以在IDB 500和DRD链路数据库599中也构造了新的二元系统模型。RTE 600也针对车辆来构造。所述RTE 600包含共同链接成集成诊断应用程序体系架构(DAA)并且被链接到车辆功能的三层级的诊断代理，该车辆功能包括具有ECU中的相应校准参数的软件。

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

在RTE 600中，软件对象之间的运行时链接或运行时绑定是由代理管理器和中介利用以XML方案定义的IDE和数据来执行的，所述数据诸如是DRD链路599中所包含的FID和DID。这使得代理链接在一起并且将代理与功能链接起来。

链接的例子是将诊断代理与引擎ECU中的校准参数相连。在使用UML的IDE 500中，这些连接可能还包括端口和协议。在遵循自动化与测量标准化协会(ASAM)的IDE 500和RTE 600中，将定义与车辆中的ECU有关的测量、校准和诊断(MCD)的附加存取方法。这些存取方法将仍被包含在DRD链路599中并被表示为具有嵌入式数据的XML方案。

参照图8，生命周期诊断方法管理分布式系统880中的车辆。所述分布式系统包括：数据库881，服务器882，车辆884，开发、制造和服务工具886、888、890，以及诸如TCU 892和ECU 894之类的车辆内部的模块。所述方法用以定义该系统的体系架构是ISO开放系统互连(OSI)七层参考模型。所述层为：应用层、表示层、会话层、传输层、网络层、数据链路层和物理层。所述DAA包括节点的七层“堆栈(stack)”的上三层，而所述TOI包括所述堆栈的下四层。

根本原因追踪随生命周期往返工程而出现，所述生命周期往返工程将车辆RTE 600(图6)中的所检测到的故障与IDE 500(图5)中的模型的元素链接起来。所述链接是通过使用存储在数据库中的IDE500链接来实现的。通过追踪利用IDE 500中的工具构造的链接，能够确定需求、设计和实施中的根本原因的候选者。

螺旋生命周期过程是由车辆RTE 600(图6)中的协作、自主诊断代理通过故障的可能检测来触发的。所述代理将应用大量能够分成几类的算法和技术：基于模型的诊断(MBD)、基于学习模型的诊断(LMBD)或者基于知识的诊断(KBD)。目前的OBD诊断代理使用常常应用指数移动平均法的MBD来设计容许的类型1和类型2统计误差分布图，所述指数移动平均法是一阶卡尔曼滤波器。

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

LMBD代理能够应用基于时间-频率的性能评估技术来避免使用(有误差的)模型进行过滤和检测信号有故障。时间-频率分析(TFA)提供了一种用于管理表示系统正常行为的信号或信号集的组合时频表示的方法。所述行为能够随时间和频率而变化。TFA是一种用于检测缓慢降级(degradation)和突发故障的方法。新开发的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中的相应车辆功能的诊断之间的往返工程。所述功能被表示成具有对象的模型。因为代理、过程、工具和链接在螺旋过程中一起工作以经过车辆的生命周期来学习模型错误，所以所述方法被称作基于生命周期学习模型的诊断。

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

优选地，所述IDE 500是带有用于开发和维护诸如动力系电子设备之类的车辆功能的开发工具集合的计算实验室和实验驱动环境，其包括：用于引擎和传动的ECU、传感器和致动器，诸如照明系统的ECU、传感器和致动器之类的车身电子设备，以及诸如防抱死制动系统(ABS)的ECU、传感器和致动器之类的车底盘电子设备。所述车辆功能是在诸如动力系和相应的子系统(诸如，发动机冷却)之类的系统中实施的。这些系统和子系统包括硬件和软件这两者。所述IDE 500还被用于开发企业应用软件(可替换地称作信息技术或IT软件)，以支持车辆制造和服务操作。

实施车辆功能的软件通常运行在驻留于车辆上的电子控制器(ECU)和可选的远程信息处理控制单元(TCU)上。所述应用软件运行在诸如服务器和PC之类的计算机上并且是供诸如诊断扫描工具之类的服务工具使用的。用于服务操作的车辆诊断软件的开发通常称作创造(authoring)。车辆上的诊断软件被称作车载诊断(OBD)。

在图9-18中举例说明了用在IDE 500(图5)的方法中的过程。随着跟随这些过程，IIDE 500中的链接工具构造DRD 599中的信息，以将RTE 600中的诊断应用程序和代理与IDB 500链接起来。那些代理读取DRD 599以找到与DID相链接的FID。

图9是根据本公开内容的示例性实施例举例说明车辆产品开发生命周期900的过程图。经其生命周期的特定车辆车型年的产品开发过程在概念上被划分成三个阶段，这三个阶段包括：开发阶段902、制造阶段904和服务阶段906。开发、制造和服务活动需要大量软件的管理。软件创建车辆功能的主要部分和商业信息系统的主要部分来支持车辆的生命周期。

制造和服务性能的开发在开发阶段902期间出现，该开发包括用于制造和服务的工具。性能被定义为具备知识的人员、工具、技术和过程。存在表示性能的结构的相关体系架构，该体系架构包括由工具和技术来表示的商业信息系统。在所述商业系统中存在大量的软件。所述相关体系架构还包括包含其子系统的车辆的结构，所述子系统包括其车载信息系统。在车辆中还存在车载诊断(OBD)系统。这个OBD系统包括大量软件。政府管制需要OBD系统的一部分，以通过监控车辆的排气控制系统的工作来间接地监控车辆的排放。典型地，在车辆的动力系ECU中存在几乎与控制软件一样多个诊断软件。

车辆上的信息系统典型地包括许多电子控制器(ECU)。车辆典型地具有五十或更多个ECU。这些ECU包含大量软件。车辆的体系架构及其制造和服务系统都是在开发期间完全定义好的。所述开发阶段902典型地从先前在先于开发阶段902的研发(R&D)阶段(未示出)中确定的大部分体系架构开始。典型地，车辆模型的体系架构模型从平台模型中导出，所述平台模型包括动力系、车底盘本体及其它子系统组件。

产品开发过程允许把车辆和商业系统两者的开发、制造和服务作为产品。所述过程与相应的商业系统一起工作，所述商业系统在开发、制造和服务期间对车辆提供支持。

所述产品和商业系统都是由所述过程来支持的，所述过程是组织性能的部分。所述性能具有相关的体系架构。所述体系架构与车辆和商业系统两者相关。所述性能包括：具备人员及其知识的内部和外部(外包)服务、应用程序、工具、平台、组件和技术。所述性能力支持车辆作为产品并且支持供应和服务链中的商业系统。这些链遍及整个生命周期地支持原始设备制造商(OEM)和车辆作为产品。

车辆的生命周期通常持续超过十年。所述开发阶段902约为两至三年，继之以用于若干车型年的几年制造阶段904。所述制造阶段904继之以许多年的服务阶段906。特定车辆的服务阶段906的最初部分通常包括：三年或三年以上的原厂件维修(OES，original equipmentservice)保修期，继之以包括独立的后继市场(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-RTE912中。具备开发工具的单个IDE 914为所有阶段所共有并且被链接到每个特定的RTE 908、910、912。所述IDE 914将通常被应用在供应和服务链中，以及被应用在OEM及其商业伙伴中。所述特定RTE908、910、912经由DRD链路916被连接到IDE 914。

图10是依照本公开内容的示例性实施例举例说明在制造原型周期的生命周期的开发阶段902(图9)期间所使用的螺旋生命周期过程1000的过程图。

产品开发过程的开发阶段902(图9)被用来以螺旋子过程1000开发原型。所述子过程800适合在开发阶段902之内。所述车辆模型(及其待开发的支持商业系统)包括：需求、设计和实施的类别中的组件。开发通常从活动开始以确定和规定一些部分的车辆需求模型及其支持商业系统，然后开发继续确定和规定一些部分的车辆设计模型及其支持商业系统，该支持商业系统包括具有其开发、制造和服务工具的RTE。

开发工具通常支持设计模型的仿真，该设计模型从而允许进行测试而无需完全实施车辆和支持系统。具有诸如硬件在环(HIL，hardwarein loop)或软件在环(SIL)之类的仿真和测试性能的开发工具被用来在可获得完整的车辆之前许可子系统的渐增性开发。随着开发继续进行，能够确定和规定一些部分的实施模型。所述螺旋过程被用来递增地完成部分需求、设计和实施。所述螺旋过程许可跟随设计的诸如实施确定和技术规范之类的反复正序，或者跟随设计或实施的诸如需求开发之类的逆序。现代软件工程和相应的工具鼓励在开发期间使用螺旋过程，以加快开发速度、提高质量和降低开发成本。

图11是根据本公开内容的示例性实施例举例说明螺旋生命周期过程1100的过程图，其中具有并发的开发和服务工作的周期。

所述生命周期螺旋过程1100是必需的，因为在车辆生命周期的服务阶段期间，将会遇到故障和异常。故障是先前已经分析过的故障并且是根据故障模式模型预测出来的。用于确定根本原因的程序可能是已知的并且能够有效地被应用。故障通常能通过包含调换或替换部件的补救程序而被实地校正。

异常是先前尚未分析过的故障并且不是根据故障模式模型预测出来的。大部分的异常将具有模型误差中的根本原因、诸如软件错误。模型错误将在车辆的实施和/或其支持商业系统中被发现。这些错误的校正必须通过返回到开发阶段来执行。如所示，所述开发阶段与服务工作同时进行。

图12是根据本公开内容的示例性实施例举例说明包含作为概念“V”周期的原型周期1200的车辆开发阶段的过程图。

开发阶段902(图9)包括后面跟着“V”形的原型周期1200。所述“V”始于作为需求的一些部分的车辆模型和商业系统的开发，然后可选地前进至部分设计模型的开发，以及然后可选地前进至部分实施模型的开发。在“V”的底部，开发活动的焦点接着转入已经开发出来的部分模型的集成、测试、校准和验证。

“向下周期”在该图的左边，而“向上周期”在该图的右边。水平地跨越“V”的是待集成、待测试、待校准或待验证的模型的对应部分。在局部被开发之后，能够通过像模拟这样的方法来集成、测试和验证需求的组件。早期的原型“V”周期可能仅仅包括需求的开发和测试。在已经开发出一些部分的设计或实施模型之后，可以利用车辆和商业系统的先前部分的模型来集成、测试和验证那个部分的模型。每个原型周期开发、集成、测试和验证更多部分的模型，该模型具有包括需求、设计和实施的组件。

图13是根据本公开内容的示例性实施例举例说明生命周期方法如何使用螺旋过程经过需求、设计和实施进展的过程图。

开发阶段902(图9)进展经过原型制作周期1302、1304、1306。每个周期最初穿过“V”周期的“向下周期”，该“向下周期”包括就需求的属性、继而是设计的属性以及最后是实施的属性而言的模型的开发。早期的“向下周期”仅仅需要在键入“向上周期”之前开发需求以便开始测试和验证所述需求。开发阶段中的大部分原型制作周期将包括就“向下周期”中的需求、设计和实施的属性而言的模型的开发。

图14是根据本公开内容的示例性实施例举例说明生命周期方法如何应用螺旋子过程的过程图。

开发阶段902(图9)包括原型周期1400。正如举例说明的那样，所述周期1400使用螺旋过程来穿过最初在“向下周期”中的“V”。利用所述螺旋过程，开发出原始模型的部分需求属性，然后进行测试，继之以正在开发部分设计，然后进行测试，然后开发部分实施属性，然后进行测试。

图15是根据本公开内容的示例性实施例举例说明如何利用所链接的IDE和RTE来应用生命周期方法的过程图。

开发阶段902(图9)具有原型周期1500并且使用螺旋过程来穿过“V”。在开发部分模型的过程中，IDE 1502是必需的。在测试、校准和验证部分实施模型的过程中，RTE 1504是必需的。为了有效地沿着所述螺旋过程移动，应该经由DRD链路1506来链接IDE 1502和RTE 1504。所述IDE 1502主要被应用在“V”的顶部和中间上，并且RTE 1304被应用在“V”的底部上。穿过“V”的螺旋过程是利用所链接的IDE 1502和RTE 1504来启用的。所述链接在“向下周期”和“向上周期”期间是必需的。在“向下周期”中，信息流主要是从IDE 1502到RTE 1504的，因为所述焦点位于具有作为RTE 1504的实施方案的末端上。

图16是根据本公开内容的示例性实施例举例说明生命周期方法如何进展的过程图。

开发阶段902(图9)进展经过原型制作周期1602、1604、1606。每个周期最终穿过“V”中的“向上周期”，该“V”包括就实施的属性、继而是设计的属性以及最后是需求的属性而言的模型的集成、测试、校准和验证。早期的“向上周期”仅仅包含需求。稍后的“向上周期”包含需求和设计。开发阶段中的大部分的原型制作周期将包括就“向下周期”中的需求、设计和实施的属性而言的模型的开发，继之以是“向上周期”中的实施、设计和需求的集成、测验、校准和验证。

图17是根据本公开内容的示例性实施例举例说明生命周期方法如何应用螺旋子过程的过程图。

开发阶段902(图9)包括原型周期。正如举例说明的那样，所述周期使用螺旋过程1700来穿过最初在“向下周期”中并然后在“向上周期”中的“V”。利用所述螺旋过程，集成原始模型的部分实施属性然后进行测试，继之以正在开发部分设计，然后进行测试，然后是部分需求属性，然后进行测试和验证。

图18是根据本公开内容的示例性实施例举例说明如何在螺旋子过程中应用生命周期方法的过程图。

开发阶段902(图9)具有原型周期并且使用螺旋过程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-1来构造的诊断代理能够检测到RTE 600中的相应功能的模块中的故障。所述代理然后访问DRD 599来查找FID-1链接，以将信息写入到能由IDE500中的任何工具来读取或由RTE 600中的附加代理来读取的DRD 599中。如果所述代理是在ECU中并且所述ECU没有直接访问DRD 599，则所述代理就向有权访问DRD 599的TCU中的代理发送消息。

一旦链接到IDE 500，通过由RTE 600在DRD 599中创建的信息，利用IDE 500内部的链接来启用诊断到功能的往返工程。

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

在所述系统499中，所述LMBD代理2012检测由MBD代理2014所检测到的故障的超集。所述LMBD故障能够被分成两类：(1)能够实地固定的先前预期的故障，或者(2)可能是模型错误或另一种新型硬件故障的新故障。通过将MBD代理2014的输出与LMBD代理2012相比较来进行所述分类。如果所述MBD代理2014在具有统计学置信因数之前已经看到故障模式，那么该故障可能不是模型错误。如果所述MBD代理2014具有表示先前未看到的新故障模式的低置信因数，那么需要研究模型错误并且告诉服务技术人员不实地调换部件。

当RTE代理将信息写入到DRD链路599(图6)中时，进行研究，这使得IDE 500(图5)能将故障追溯到在实施、设计和需求的级上表示的模型的级。

所述系统499识别出哪些功能被链接到所述故障。可以在IDE 500(图5)中运行模拟，以复制故障模式。所述模拟帮助确定根本原因。

图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结束。

本领域技术人员将会认识到的是，在这里所描述的系统能够利用许多软件配置、网络配置等等加以实施。

在这里所举例说明的各种实施例的逻辑操作被实施为：(1)计算机实施的步骤或运行在计算系统上的程序模块的序列，和/或(2)互连逻辑电路或计算系统内的电路模块。所述实施方案是依据实施本发明的计算系统的性能要求进行选择的问题。因此，构成这里所述的本发明的实施例的逻辑操作不同地被称为操作、步骤、引擎或模块。

上述各种实施例都仅仅是通过举例说明的方式来给出的，并不应将其解释成限制本发明。本领域的技术人员将容易地认识到：在不遵循在这里所举例说明和描述的实例实施例和应用程序的情况下并且在不脱离本发明的真实精神和范围的情况下，可以对本发明作出各种修改和变化，本发明的真实精神和范围是由下述权利要求来限定的。

Claims

1.一种用于基于学习模型的生命周期诊断的系统，所述系统包括：

集成开发环境，其具有内部链接的软件工具；

运行时环境，其具有内部链接的、检测故障的代理；和

集成开发环境和运行时环境之间的双向链路；

借此，在运行时环境中检测到的故障被追溯到集成开发环境以确定模型错误。

2.根据权利要求1所述的系统，其中，所述集成开发环境包括被链接在一起的需求管理工具、设计工具和实施工具。

3.根据权利要求2所述的系统，其中，所述需求管理工具包括面向对象的需求管理工具和基于问题的信息系统需求管理工具。

4.根据权利要求2所述的系统，其中，所述设计工具包括面向对象的模型驱动的功能设计工具、基于知识的诊断设计工具和基于模型的诊断设计工具。

5.根据权利要求2所述的系统，其中，所述实施工具包括软件功能代码生成、管理和部署工具以及软件诊断代码生成、管理。

6.根据权利要求1所述的系统，其中，所述运行时环境包括诊断代理。

7.根据权利要求6所述的系统，其中，所述诊断代理包括基于模型的诊断代理和基于学习模型的诊断代理。

8.根据权利要求1所述的系统，其中，所述运行时环境包括数据库、服务器软件工具、中介和诊断代理。

9.根据权利要求1所述的系统，其中，所述双向链路是DRD链路。

10.根据权利要求9所述的系统，其中，所述DRD链路包括数据库。

11.根据权利要求10所述的系统，其中，所述数据库是分布式数据库。

12.一种用于车辆的基于学习模型的生命周期诊断的系统，所述系统包括：

集成开发环境，其包括链接在一起的需求管理工具、设计工具和部署工具；

运行时环境，其具有链接在一起的、检测故障的应用程序、中介和代理；和

集成开发环境和运行时环境之间的双向链路；

13.根据权利要求12所述的系统，其中，所述需求管理工具包括面向对象的需求管理工具和基于问题的信息系统需求管理工具。

14.根据权利要求12所述的系统，其中，所述设计工具包括面向对象的模型驱动的功能设计工具、基于知识的诊断设计工具和基于模型的诊断设计工具。

15.根据权利要求12所述的系统，其中，所述实施工具包括软件功能代码生成、管理和部署工具以及软件诊断代码生成、管理。

16.根据权利要求12所述的系统，其中，所述代理是诊断代理。

17.根据权利要求16所述的系统，其中，所述诊断代理包括基于模型的诊断代理和基于学习模型的诊断代理。

18.根据权利要求12所述的系统，其中，所述双向链路是DRD链路。

19.根据权利要求18所述的系统，其中，所述DRD链路包括数据库。

20.根据权利要求19所述的系统，其中，所述数据库是分布式数据库。

21.一种诊断软件环境中的模型错误的方法，所述软件环境包括通过链路双向链接的集成开发环境和运行时环境，所述方法包括：

检测运行时环境内的故障；

将该故障追溯到集成开发环境；以及

根据故障的追踪来识别集成开发环境中的模型错误。

22.根据权利要求21所述的方法，其中，检测故障包括使用基于模型的诊断代理来检测运行时环境内的故障。

23.根据权利要求22所述的方法，进一步包括，根据由基于模型的诊断代理检测到的故障来确定已知故障模式的根本原因。

24.根据权利要求21所述的方法，其中，检测故障包括使用基于学习模型的诊断代理来检测运行时环境内的故障。

25.根据权利要求24所述的方法，其中，检测故障包括诊断代理使用通过观察来学习模型的嵌入式数据挖掘算法。

26.根据权利要求24所述的方法，其中，追踪故障包括诊断代理将信息写入到所述链路中。

27.根据权利要求26所述的方法，其中，追踪故障包括将所述链路中的信息读取到集成开发环境中。

28.根据权利要求27所述的方法，其中，识别所述模型错误包括识别被表示在实施、设计、和需求级的模型级中的模型错误。

29.一种诊断软件环境中的模型错误的计算机程序产品，改计算机程序产品可由计算系统来读取并编码指令，所述软件环境包括双向链接的集成开发环境和运行时环境，所述计算机过程包括：

检测运行时环境内的故障；

将该故障追溯到集成开发环境；以及

根据故障的追踪来识别集成开发环境中的模型错误。

30.根据权利要求29所述的计算机程序产品，其中，检测故障包括使用基于模型的诊断代理来检测运行时环境内的故障。

31.根据权利要求30所述的计算机程序产品，进一步包括根据由基于模型的诊断代理所检测到的故障来确定已知故障模式的根本原因。

32.根据权利要求29所述的计算机程序产品，其中，检测故障包括使用基于学习模型的诊断代理来检测运行时环境内的故障。

33.根据权利要求32所述的计算机程序产品，其中，检测故障包括诊断代理使用通过观察来学习模型的嵌入式数据挖掘算法。

34.根据权利要求32所述的计算机程序产品，其中，追踪故障包括诊断代理将信息写入到所述链路中。

35.根据权利要求34所述的计算机程序产品，其中，追踪故障包括将所述链路中的信息读取到集成开发环境中。

36.根据权利要求35所述的计算机程序产品，其中，识别所述模型错误包括识别被表示在实施、设计、和需求级的模型级中的模型错误。