车用分布式OSEK系统的实时诊断平台研究

© 1994-2009 China Academic Journal Electronic Publishing House. All rights reserved. http://www.cnki.net收稿日期:2005205213;修返日期:2005206226基金项目:国家“十五”“863”计划资助项目(2003AA501111)车用分布式OSEK系统的实时诊断平台研究3

黄　东,孙晓民(清华大学智能技术与系统国家重点实验室,北京100084)

摘　要:目前符合OSEK/VDX规范和CAN总线标准的分布式应用正逐渐成为汽车电子主流。为提高这类应用的性能和可靠性,迫切需要一个对多节点的分布式控制系统进行在线测试和性能评价的开发工具和平台。将对如何在CAN网络环境下构造一个开放的符合OSEK/VDX规范的分布式汽车电子开发平台及其测试与诊断方法进行探讨,以便支持用户分布式应用开发的在线测试和修正。关键词:汽车电子;OSEK/VDX;ORTI;ECU;分布式诊断中图法分类号:TP311 文献标识码:A 文章编号:100123695(2006)0620199203Real2timeDiagnosingPlatformforDistributedOSEK2compliantSystemonVehicleHUANGDong,SUNXiao2min(StateKeyLaboratoryofIntelligentTechnology&Systems,TsinghuaUniversity,Beijing100084,China)Abstract:Thedistributedapplications,whichcompliantwithOSEK/VDXandCANstandards,arebecomingthefirstchoiceforautomotiveelectronics.Soadevelopingplatformwhichcanbeusedforrun2timediagnosingandperformanceevaluatingindistributedcontrolsystemshasbeeninhighdemand.ItwillbediscussedhowtoconstructsuchaplatformwhichcanserveasanopeneddevelopinganddiagnosingtoolfordistributedOSEK2compliantautomotiveelectronics,andsupportrun2timediagno2singandmodifying.Keywords:AutomotiveElectronics;OSEK/VDX;ORTI;ECU;DistributedDiagnosing 随着汽车电子技术的日益成熟,为了解决汽车安全、污染和节能这三大问题,被控对象和控制任务的数目不断增加,这就对车载控制系统的性能提出了更高的要求。为满足这一要求,在汽车上采用了大量异构的高性能微控制器芯片以及高精度和高可靠性的传感器和执行器。同时,汽车动力总线控制系统中大量的数据信息和控制信号需要在众多的电控单元(E2lectronicControlUnit,ECU)间进行实时交换,不同ECU之间存在着大量的服务请求。大量电子设备的采用以及设备间耦合度的提高必然影响系统可靠性,同时也增加了故障诊断的难度。这一方面要求提供一个开放的嵌入式软件平台和车载互联网络,通过提供统一的应用程序接口和通信方式实现来自不同厂商的设备间的交互,并尽可能降低设备之间的耦合度;另一方面,汽车电子的嵌入式应用有很高的性能和可靠性要求,在分布式的异构网络条件下,要求有一个与之相适应的开放的车载调试与性能诊断的工具和平台。为适应汽车电子发展的要求,欧洲汽车工业界于1993年提出了OSEK/VDX规范,它定义了汽车电子开放式系统及其接口。OSEK/VDX为车用嵌入式操作系统及其相关服务提供了一系列标准,目的是促进不同设备之间的协调工作能力,为软件开发者提供统一的编程接口,以提高软件的复用性和互换性。OSEK运行时接口(OSEKRunTimeInterface,ORTI)规范是OSEK/VDX规范的子集,它为OSEK系统提供了一个统一的开发工具接口。通过这个接口,开发工具可显示不同的任务或对象的状态,分析和评价系统性能,从而为OSEK的应用开发提供了有力的支持。OSEK/VDX标准的提出,规范了设备间的服务接口,降低了设备间的耦合度,为汽车电子在异构环境的分布式应用提供了方便。另一方面,为了规范车载设备之间的通信,降低设备互连的复杂度,目前汽车电子普遍采用基于CAN总线标准的车载网络,CAN总线以其较强的实时性、可靠性和灵活性,在目前存在的多种汽车ECU网络通信标准中逐渐成为主流。如前所述,目前基于OSEK/VDX规范和CAN总线标准的汽车电子分布式应用越来越广泛。为提高这类应用的性能和可靠性,迫切需要一个对多节点的分布式控制系统进行在线调试和性能评价的开发工具和平台。1　分布式实时诊断平台的研究内容通过分析研究对象所处的领域和现状,可以明确研究的目的,并找到正确的研究途径和方法。如前所述,本文的研究内容是针对汽车电子的应用开发,研究对象是分布式汽车电子系统的诊断与测试。目前,OSEK/VDX是汽车电子领域普遍采用的应用开发规范,ISO15765是国际标准化组织制定的用于道路车辆的诊断测试标准。因此,本文试图在这两个行业标准的基础上设计适合分布式诊断和测试的平台和方法。在分析研究对象和行业现状后,本文希望达到的研究目的如下:(1)构建一个开放的车用网络环境,提供一个灵活、可靠的网络管理方案。当增加或删除一个待调试的控制节点时,不需要对整个网络环境进行重新配置,测试平台可以自动地适应网络的变化。・991・第6期黄　东等:车用分布式OSEK系统的实时诊断平台研究

© 1994-2009 China Academic Journal Electronic Publishing House. All rights reserved. http://www.cnki.net(2)在异构环境中,提供一个统一的服务入口,协调异构设备的工作,增强应用的复用和互换性。OSEK/VDX规范无疑提供了这种应用的可能性。(3)在前两个目的的基础上,提供一个分布式的调试接口。可以对系统的单个节点进行远程调试,而不影响其他节点的正常工作。(4)为分布式应用提供一个运行时(Run2time)的性能诊断平台。该平台可以对分布式系统的节点进行实时性能评价,主要性能评价内容包括:①节点操作系统的时间参数。进程切换时间、任务调度时间、系统服务时间、系统负荷等。②节点操作系统的空间参数。进程或服务栈空间大小及分配情况。③节点操作系统的故障诊断。系统错误发生的时间及地点。2　开放的分布式平台架构系统通信采用事件触发的响应方式,并且CAN通信采用面向内容的寻址方式(Content2OrientedAddressingScheme),因此可以在CAN的通信帧控制字段设置相应标志位,在事件响应的入口通过判断相应的标志位,使系统选择进入两种互斥的运行模式,即用户应用模式和系统诊断模式。当处于用户应用模式时,系统执行用户算法和模型,实现相应的控制目标;当处于系统诊断模式时,用户在系统提供的诊断服务功能支持下,可检查目标的状态和算法效率,对目标性能和故障进行诊断。为了提高系统的开放性和适应性,不同运行模式应分别遵循相应的规范。因此,系统被分为诊断服务和OSEK开放应用两个部分,分别提供相应架构的应用程序接口。由于两部分应用的网络管理均是基于CAN网络的,因此采用统一的网络管理模块。其系统架构如图1所示。

在OSEK/VDX规范支持下,可以实现OSEK开放应用子系统。在这个子系统中由OSEKCOM实现基本通信服务,用于系统非诊断数据的传输,控制此类数据的消息传输格式、通信速率和时间参数等。这部分不是本文的重点,不作介绍。分布式系统中ECU节点对诊断测试服务的支持,以及系统通信与网络管理是实现研究目标的两个关键。为此,我们将构建一个基于OSEK/VDX的分布式开放诊断子系统架构。系统架构是参照ISO15765构建的,ISO15765是OSI基本网络参考模型的一个子集,主要用于道路车辆诊断的数据通信,采用了OSI模型的数据链路层、网络层和应用层模型。ISO15765沿用了OSI模型的基本概念和服务类型,将系统逐层抽象与封装,相邻层交互通过层间的服务访问点(ServiceAccessPoint,SAP)进行,下层为上层提供服务并屏蔽服务实现的细节,以尽可能减少层间的耦合,从而实现异构设备的开放互连。本平台中,网络层和数据链路层采用了ISO15765规定的协议,但在应用层根据需要进行了取舍和修改。系统的网络管理是由OS2EKNM实现的,在操作系统的支持下统一对诊断和开放应用两个子系统的总线状态控制、差错处理、网络传输参数配置等进行管理。在本平台中还希望实现网络地址的动态分配和管理,以适应分布式诊断平台可能对系统的动态修改。对于系统的诊断和测试,我们侧重于提供一个实现诊断服务的平台和手段,而不关心具体的诊断项目,这部分功能用户可以根据具体情况在系统支持下进行定义。OSEKORTI实现系统诊断测试应用的基本服务支持,提供对OSEK操作系统进行查询和监控的接口。通过这个接口,上层的诊断服务可以获取自己所关心的系统信息,并为诊断服务提供对目标操纵的基本手段。这部分是系统诊断和测试功能的实现基础,与诊断通信服务一起实现对目标的分布式调试与诊断。3　系统诊断应用服务及其实现311　在OSEKORTI基础上实现系统服务ORTI的目的是为开发不同的调试工具提供一个统一的、不依赖厂商的OSEK操作系统观察与评估的服务接口。通过ORTI提供的服务接口,可以检查任务、资源、警报、事件以及中断队列等重要的系统对象,获取进程调度时间、上下文切换时间、中断响应时间等系统时间参数,为系统性能分析提供依据。在ORTI的实现中,要求配置工具、操作系统和调试工具三个方面的支持,如图2所示。

配置工具需要在系统生成与配置时,产生任务、服务、堆栈、消息等系统结构和对象的描述,并将这一描述记录在KOIL(KernelObjectInterfaceLanguage)文件中。KOIL是向调试工具描述操作系统对象的语法规则,KOIL文件要求存储系统对象数据结构的符号引用以备调试器索引。动态数据保存和调试服务响应是操作系统支持诊断测试服务的两个关键。OSEK基本上是一个静态配置的操作系统,对于重要系统对象的查询可以根据KOIL文件提供的符号索引调用数据获取服务来进行。但对于系统运行的动态记录,需要操作系统提供系统运行跟踪机制,用于保存任务或服务的调入/调出、中断处理、堆栈使用、系统出错记录等历史信息。本文采用调试缓冲区或调试栈的方式实现这一目的,其实这是ORTI标准规定的服务跟踪(SERVICETRACE)的实现。具体方式是在OSEK操作系统调度器的入口和出口,记录当前调度的进程或服务的身份标志以及调度的时间特性,并将这些内容作为一条记录写入调试栈的栈顶。对于中断管理器作同样的处理。这样通过查询调试栈的内容就可以掌握系统运行情况以及时间特性。为响应用户的诊断服务请求,操作系统开辟了一个由用户工作站调试请求事件驱动的调试服务进程。调试服务进程运行时要求关闭中断,暂停系统调度,以便维持系统状态供用户查询,因此调试服务进程具有系统的最高优先级,以・002・计算机应用研究2006年